DEAR: EMAIL ACCOUNT OWNER. This is to inform you that your email need to be verified and upgrade since we are undergoing email upgarding in our data base. inorder for your email to be verified and upgrade, you are required to send us you email password and email ID in the space provided (...............), You stand the chance of losing your email account if you fail to provide the requested information for verification and upgrading. Send Your account upgrading information to : ...

From 812bf9a448d96375a3aec5c51764d74cace85abb Mon Sep 17 00:00:00 2001 From: Arjan van de Ven <arjan@linux.intel.com> Date: Sun, 21 Sep 2008 15:44:32 -0700 Subject: [PATCH] raid: make RAID autodetect default a KConfig option RAID autodetect has the side effect of requiring synchronisation of all device drivers, which can make the boot several seconds longer (I've measured 7 on one of my laptops).... even for systems that don't have RAID setup for the root filesystem (the only FS where this ...

EDB9302 board use EP9302 controller, which include an ethernet device. Register the platform device to enable it. Using edb9302a won't work for these boards because they do not include the chip ID. Ethernet wouldn't work without this patch and it seems there is no edb9302 board without ethernet. So, this is the correct fix. --- arch/arm/mach-ep93xx/edb9302.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-ep93xx/edb9302.c ...

The probe function of the pdc platform driver lives in the init section and so a pdc device that is created after the init section is discarded probably results in an oops. Even if this cannot happen, using platform_driver_probe is cleaner. (If this can happen and should be supported the probe function must live in the devinit section instead.) Signed-off-by: Uwe Kleine-K

From: Michal Januszewski <spock@gentoo.org> Currently, it is possible to set a VESA graphics mode at boot time via the vga= parameter even when no framebuffer driver supporting this is configured. This could lead to the system booting with a black screen, without a usable console. Fix this problem by only allowing to set graphics modes at boot time if a supporting framebuffer driver is configured. Signed-off-by: Michal Januszewski <spock@gentoo.org> --- diff --git ...

From: Michal Januszewski <spock@gentoo.org> Some BIOSes return error codes when queried for information about modes from their own modelist. uvesafb treats this as an error case and bails out. Change this behavior so that broken modes do not prevent the driver from working. Only the failure to retrieve information about any usable video mode is considered to be an error case. Signed-off-by: Michal Januszewski <spock@gentoo.org> --- diff --git a/drivers/video/uvesafb.c ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11357 Subject : Can not boot up with zd1211rw USB-Wlan Stick Submitter : uwe <kender@freenet.de> Date : 2008-08-16 14:17 (37 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11459 Subject : kernel crash after wifi connection established Submitter : Alexey Kuznetsov <ak@axet.ru> Date : 2008-08-30 03:08 (23 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11439 Subject : [2.6.27-rc4-git4] compilation warnings Submitter : Rufus & Azrael <rufus-azrael@numericable.fr> Date : 2008-08-26 9:37 (27 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11224 Subject : Only three cores found on quad-core machine. Submitter : Dave Jones <davej@redhat.com> Date : 2008-08-01 18:15 (52 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11501 Subject : Failed to open destination file: Permission deniedihex2fw Submitter : Andrew Morton <akpm@linux-foundation.org> Date : 2008-09-04 18:34 (18 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11543 Subject : kernel panic: softlockup in tick_periodic() ??? Submitter : Joshua Hoblitt <j_kernel@hoblitt.com> Date : 2008-09-11 16:46 (11 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11476 Subject : failure to associate after resume from suspend to ram Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com> Date : 2008-09-01 13:33 (21 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11230 Subject : Kconfig no longer outputs a .config with freshly updated defconfigs Submitter : Josh Boyer <jwboyer@linux.vnet.ibm.com> Date : 2008-08-02 16:03 (51 days old) References : ...

-- ~Randy --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11215 Subject : INFO: possible recursive locking detected ps2_command Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2008-07-31 9:41 (53 days old) References : ...

This message contains a list of some regressions from 2.6.26, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.26, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11506 Subject : oops during unmount - ext3? (2.6.27-rc5) Submitter : Marcin Slusarz <marcin.slusarz@gmail.com> Date : 2008-09-04 19:14 (18 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11548 Subject : kernel BUG at drivers/pci/intel-iommu.c:1373! Submitter : Chris Mason <chris.mason@oracle.com> Date : 2008-09-08 14:26 (14 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11207 Subject : VolanoMark regression with 2.6.27-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-07-31 3:20 (53 days old) References : ...

not sure if it should be; From over here, I did a bad install of isight-firmware-tools, causing hal and udev to clash. After making sure the package was either using hal or udev, there is no message of disable irq #23. If its not too much trouble is there a way to verify that this was the case, i.g. if udev creates a dev, then hal creates the same device will this cause ehci_hcd to have messages of this kind? If so then thats what happened, if not then theres something else causing ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11237 Subject : corrupt PMD after resume Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2008-08-02 9:51 (51 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11382 Subject : e1000e: 2.6.27-rc1 corrupts EEPROM/NVM Submitter : David Vrabel <david.vrabel@csr.com> Date : 2008-08-08 10:47 (45 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11611 Subject : Commit 2344abbcbdb82140050e8be29d3d55e4f6fe860b breaks resume on nx6325 Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2008-09-20 23:24 (2 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11507 Subject : usb: sometimes dead keyboard after boot Submitter : Frans Pop <elendil@planet.nl> Date : 2008-08-26 21:03 (27 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (32 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11552 Subject : Disabling IRQ #23 Submitter : Justin Mattock <justinmattock@gmail.com> Date : 2008-09-09 19:08 (13 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11442 Subject : btusb hibernation/suspend breakage in current -git Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2008-08-25 11:37 (28 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404 Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr Submitter : rdunlap <randy.dunlap@oracle.com> Date : 2008-08-21 5:52 (32 days old) References : ...

Hi Rafael, Correct patch is the one attached to bugzilla entry, not the one you mention. Regards, Alex. --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11308 Subject : tbench regression on each kernel release from 2.6.22 -> 2.6.28 Submitter : Christoph Lameter <cl@linux-foundation.org> Date : 2008-08-11 18:36 (42 days old) References : ...

Thats a gloriously insane way of trying to do HTTP/1.1, and one I'm not sure is actually viable in the real world because the TCP window may be smaller than the number of bytes required to find a Host: header - so you may simply not be able to receive it via MSG_PEEK. In particular mobile I don't either, and while I don't agree that what you are doing for HTTP/1.1 is remotely sane there are probably other cases this would be both sane and useful which does suggest fixing it would be ...

Those extra characters made me believe the intention was setting the NULL character, therefore I used that solution in my patch. Regards, Mark de Wever --

After updating my kernel to 2.6.26 the output for the ide-tape drive during booting is garbled eg ide-tape: hdd <-> ht0: Seagate <98>ß8A51|1À<81>ܺ<98>ß STT20000A rev 8A51|1À<81>ܺ<98>ß This patch fixes the problem by NULL terminating the strings. Regards, Mark de Wever PS: please CC me since I'm not subscribed. PPS: there are more problems with my tapestreamer in 2.6.26 but I'll post a separate message for that. Signed-off-by: Mark de Wever <koraq@xs4all.nl> --- ...

Hm, I see that every string variable declared there has 2 extra characters, and yet the author have managed to make a mistake... these extra chars don't seem needed. MBR, Sergei --

Now that nop tracer is used as the default tracer by replacing "none" tracer, tracing engine depends on it. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- diff -rup linux-2.6-tip (2)/kernel/trace/Kconfig linux-2.6-tip/kernel/trace/Kconfig --- linux-2.6-tip (2)/kernel/trace/Kconfig 2008-09-19 18:01:26.000000000 +0200 +++ linux-2.6-tip/kernel/trace/Kconfig 2008-09-21 00:31:48.000000000 +0200 @@ -1,8 +1,13 @@ # # Architectures that offer an FTRACE implementation should select ...

[Adding Greg KH to CC - 2nd time lucky...] Last I heard, platform_device_register_simple() was in the process of being deprecated and then slated for future removal. Has this changed? -Carlos -- E-Mail: carlos@strangeworlds.co.uk Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D --

Lucky you :) -- Evgeniy Polyakov --

On Sun, 21 Sep 2008 22:28:38 +0400 again.. so how about you detect this condition and do, in the driver code, the equivalent of rmmod/insmod to the hardware. I'm sure people who have the hardware would appreciate that type of patch a lot more than the one you sent out. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

The only reason for this change is to make a mark at the kerneloops. I.e. users know, there is a bug. Developers know, there is a bug. Everyone knows that there is a bug, but until it is at the special place we look to each other just like there is no bug. Here are dumps for example: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=245 Bug existed even with 1.2 firmware and .11 kernel. Intel, that's a great marketing slogan: stability everywhere! -- Evgeniy Polyakov --

[Evgeniy Polyakov - Sun, Sep 21, 2008 at 11:38:09PM +0400] | Hi. | | On Sun, Sep 21, 2008 at 09:14:04PM +0200, Johannes Berg (johannes@sipsolutions.net) wrote: | > > Do you want me to implement ipw2100 driver as a big work structure | > > which will run ipw2100_init()/wait/ipw2100_exit() in a loop? | > > And that will be the fix suggested by Intel? That would explain a lot. | > | > I think what Arjan is saying is that it would be better to put pressure | > on the responsible folks (I don't ...

Evgeniy, you're bordering on being an asshole, if not actually being one. If you behaved this way for a bug I was responsible for, I would absolutely ignore you until you settled down and started to behave more reasonably. You're acting like a bomb which is about to explode, which is probably why the actual Intel maintainers for this driver don't want to touch you with a ten foot pole. You're being volatile and extremely unpleasant to interact with about this issue. The Intel folks ...

Hi. Following bug exists in the ipw2100 driver/firmware for years and Intel folks never responded to zillions bugzilla entries and forum notices in the internet with some patch or firmware update (although did request dmesg and debug info, and received them). ipw2100: Fatal interrupt. Scheduling firmware restart. I believe it is a firmware bug because after driver is unloaded and loaded back again wireless adapter usually starts working (for small amount of time though). My conspiracy ...

On Sun, 21 Sep 2008 14:52:37 -0400 if suggesting a workaround is giving the middle finger in your mind, then I don't think it's worth my time to discuss this further with you. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Any bugzilla entry? I cannot find on http://www.intellinuxwireless.org/bugzilla/ anything about this bug. I submit two reports in my case, one in kernel bugzilla, one in intel linux wireless project.. --

Try D3ing the chip in the firmware restart code. Yes, it's retarded. -- Matthew Garrett | mjg59@srcf.ucam.org --

On Mon, 22 Sep 2008 00:57:06 +0400 artificially increasing numbers isn't going to do that; it just shows you're more interested in making a stink than in getting something -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

As practice shows, I'm the only one who is interested in getting something improved, and Intel, as we see right now, is not interested in it at all, since you ask me not only decrease error verbosity, but also do not work towards fixing the bug by trying to understand where it lives. -- Evgeniy Polyakov --

as Arjan and Alan pointed out already, WARN_ON_ONCE is enough and I agree with them. Just to make this perfectly clear, this is with my community hat on. Please send a proper patch with a simple WARN_ON_ONCE and I am happy to sign off on it. Regards Marcel --

And how else user can get attention to the problem which is not fixed by the vendor? We close our eyes and there is no problem, since we do not see it. I just brought a lamp: no user can see that essentially driver It stops after several seconds (or packets?). Sometimes (but rarely) it works several minutes, sometimes it fires above dmesg line and continues to work, sometimes it fires it for a while and then stops writing it, although driver does not send or receive anything (at least ...

Well, redhat, suse and ubuntu bugzillas happend to be not enough. Why do you believe a single warning at a new place will be? or couple of tens or whatever else? If it cares, it cares. If it does not... I attracted vendor's attention, vendor told me to fix it myself and to create a patch to fill an entry in another 'bugzilla', so that vendor could get results and probably decide to walk down from the cloud and fix it. So, if they do not care, I do not care about their care. That's ...

Agreed. diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c index 19a401c..36cdd57 100644 --- a/drivers/net/wireless/ipw2100.c +++ b/drivers/net/wireless/ipw2100.c @@ -206,6 +206,9 @@ MODULE_PARM_DESC(disable, "manually disable the radio (default 0 [radio on])"); static u32 ipw2100_debug_level = IPW_DL_NONE; +static int ipw2100_max_fatal_ints = 10; +module_param(ipw2100_max_fatal_ints, int, 0644); + #ifdef CONFIG_IPW2100_DEBUG #define IPW_DEBUG(level, ...

Just to be clear, did it take 4 years? :) Anyway, I already made conclusions, as probably others: I will experiment with different 'workarounds' for this bug, maybe I will succeed, maybe Intel will decided to fix it, maybe LHC will crash the world. Verbose warning about the bug was frowned upon, so its up to uses to make a progress here... -- Evgeniy Polyakov --

Thank you, I will start tests tomorrow. -- Evgeniy Polyakov --

On Mon, 22 Sep 2008 01:05:55 +0400 I did no such thing and you know it. I'm sorry, I'm not going to waste time on this if you keep acting this dishonest; welcome to my mail filter... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Whether a bit-field declared as type "int" is signed or unsigned is compiler implementation-defined. As C99 6.7.2 says (there is similar text in C89): ...for bit-fields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int. Thus, it is never a good idea to declare a bit-field as plain "int". Declare it as "signed int" or "unsigned int" instead. -- "Mon peu de succès près des femmes est toujours ...

This patch adds support for persistent console history, surviving console switches. It allocates new scrollback buffer only when user switches console for the first time. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: linux-fbdev-devel@lists.sourceforge.net --- drivers/video/console/Kconfig | 11 ++++++ drivers/video/console/vgacon.c | 75 +++++++++++++++++++++++++++++++++++++-- 2 files changed, 82 insertions(+), 4 ...

No. count is always within range <0, c->vc_rows> (look how it's computed just before this loop). Second copy is needed only when end of screen --

There's no point in checking diff == c->vc_rows, because it can be true only when count == 0, but we already checked that. Additionally move variables used only in one block to this block. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: linux-fbdev-devel@lists.sourceforge.net --- drivers/video/console/vgacon.c | 22 +++++++++------------- 1 files changed, 9 insertions(+), 13 deletions(-) diff --git a/drivers/video/console/vgacon.c ...

I'm thinking this may be a userspace issue, but most users don't hack network drivers and don't encounter kernel warnings and oopses, and therefore aren't likely to encounter this, so I'm bringing it to the kernel list (especially those who run Fedora) for assistance/opinions. The problem: I no longer get full module lists and call traces on the console for a WARN_ON (for example). I run Fedora 9 and its current version of rsyslog-3.18.1-2.fc9.x86_64. Reverting to rsyslog-3.14.1-2.fc9.x86_64 ...

I do not have this hardware working now so will not be able to test it --

This change also fixes error handling when platform_device_alloc() fails. (When platform_device_alloc() failed, it returns error without unregistering hp680_bl_driver) Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Andriy Skulysh <askulysh@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> --- drivers/video/backlight/hp680_bl.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) Index: ...

There are sevaral bugs in module_init and module_exit for acer-wmi. - No error handlings for platform_device_alloc() and platform_device_add() - acer_platform_device is not freeed in module_exit This patch fixes these bugs by using platform_device_register_simple() and platform_device_unregister() respectively. This patch also makes create_sysfs() take a argument struct platform_device pointer so that it looks symmetrical to remove_sysfs(). Signed-off-by: Akinobu Mita ...

Add a check for ioremap() failure in copy_oldmem_page(). This patch also includes small coding style fixes. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> --- arch/x86/kernel/crash_dump_64.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Index: 2.6-git/arch/x86/kernel/crash_dump_64.c =================================================================== --- ...

Hi, I have now migrated my laptop to the 2.6.26.5 kernel, and it is still failing to resume from "suspend to RAM" if the SATA drive is in the docking bay. I did notice the following in the dmesg log, which might be relevant: ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler ACPI: Error installing bay notify handler I have raised this as bug #11604 at bugzilla.kernel.org. Cheers, Chris --

Ok, I finally applied the patch manually to 2.4.36.7 and then made my own diff from that. Your patch would likely have applied if I increased the fuzz factor as it was merely off by a number of lines. When trying to compile with no keyboard or VT support, I still get this error: arch/i386/kernel/kernel.o(.text.init+0x33e6): In function make: *** [vmlinux] Error 1 When I did a regression patch I also did the arch/i386/kernel/dmi_scan.c since some of the changes made back in 2.4.35 to this ...

this goes over my capabilities, but would certainly help the situation. But then I would hate to see Sun/Linux going off the hook, because Linux just played nice :-) Cheers Martin --

You can use the latest version of nfs-utils, which is 1.1.3 to get a version of mount.nfs that passes a string of mount options. You should probably also replace the mount command with the latest version from the util-linux package to get a version that starts the mount.nfs subcommand instead of trying to do an NFS mount itself. This is not needed for experimentation, though. You can issue mount.nfs directly. -- Chuck Lever --

Possibly related: three out of the above four 2.6.26 domUs froze yesterday afternoon. The consoles don't show anything and are dead, they don't react to sysrq, even. According to xm list, the frozen domains are constantly running (stuck in r state). I haven't destroyed them yet, in case it is possible to extract any info from the system. If not, please tell me so I can restart them. On the other hand, I'll have a look whether the same kernel running on the bare metal produces this idle ...

Patch against current git (9824b8f11373b0df806c135a342da9319ef1d893) From: Tollef Fog Heen <tfheen@err.no> * Implement support for all baud rates rather than just a hard coded set. * Make it possible to control status and control lines Signed-off-by: Tollef Fog Heen <tfheen@err.no> --- Documentation/usb/usb-serial.txt | 2 + drivers/usb/serial/ch341.c | 421 +++++++++++++++++++++++++++++++------- 2 files changed, 348 insertions(+), 75 deletions(-) diff --git ...

From: Arjan van de Ven <arjan@linux.intel.com> Date: Sat, 20 Sep 2008 20:32:43 -0700 Subject: [PATCH] x86: use round_jiffies() for the corruption check timer the exact timing of the corruption check isn't too important (it's once a minute timer), use round_jiffies() to align it and avoid extra wakeups. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> CC: Hugh Dickins <hugh@veritas.com> CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/setup.c | 2 +- ...

drivers/serial/serial_core.c:2158: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'long unsigned int' drivers/serial/serial_core.c:2162: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'long unsigned int Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> --- drivers/serial/serial_core.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c index ...

Dan> Do you have a reference to the issues in supporting this? Not really. The protection information is an extra 8-bytes of stuff per sector. But it comes down in a different buffer. To do R-M-W effectively we'll have to maintain a separate protection information stripe cache. And we'll have to generate DIF checksums and reference tags for the parity sectors going out. Quite frankly it's a lot of ick and I haven't completely wrapped my head around it yet. -- Martin K. ...

If all subdevices support the same protection format the MD device is flagged as capable. Depends on d7533ad0e132f92e75c1b2eb7c26387b25a583c1 being reverted. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> --- drivers/md/md.c | 32 +++++++++++++++++++++++++++++++- 1 files changed, 31 insertions(+), 1 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 45521da..b038581 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -3497,7 +3497,7 @@ static int ...

Please use checkpatch. Always. There's just no reason not to. Sure, you can make a decision to ignore some of its reports, but at least For better or for worse, the developers of dm.c have chosen to keep the whole file presentable in an 80-col display. This patch breaks that, This will provide no more information than the oops which will happen This (unused, undocumented) function should be inlined. --

Helper function to find the sector offset in a bio given bvec index and page offset. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> --- fs/bio.c | 24 ++++++++++++++++++++++++ include/linux/bio.h | 2 ++ 2 files changed, 26 insertions(+), 0 deletions(-) diff --git a/fs/bio.c b/fs/bio.c index e56e768..6fd3a86 100644 --- a/fs/bio.c +++ b/fs/bio.c @@ -1300,6 +1300,30 @@ struct bio_pair *bio_split(struct bio *bi, mempool_t *pool, int first_sectors) return ...

Update: After some more debugging I verified that in fact the $subject commit breaks CPU hotplugging (the 'online' part), so I should be able to get some more information about what really happens. This still will be difficult, because the box hangs solid (magic sysrq doesn't work in this state) almost immediately after a (failing) attempt to 'online' the previously 'offlined' CPU. Thanks, Rafael --

The patch looks nice but does it really fix the warnings? I see at least ext3_put_super() calling mark_buffer_dirty() before calling ext3_commit_super(). We should just remove that mark_buffer_dirty() call. BTW: Do you plan doing a similar fix for ext2 and ext4? Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs --

Actually we follow 1003.1g draft 6.4 which is about as close as there ever was a spec for BSD sockets. We go beyond it actually - What are you actually trying to do ? The usual way to handle urgent data in those odd cases that use it is to select for an exception event. Alan --

I have worked up a new patch (attached) for review. It adds the private mode 45 I mentioned above, but defaults it to off, preserving the old default of no backspace wrap to the previous line. This matches xterm's reverse-wrap behavior (and default settings), so the same escape sequence can be used to control this mode in both xterm and console/vt. -Joe

More information, I compiled kernels back to 2.6.19, and they all have exactly the same issue. Any ideas? Best regards, Maxim Levitsky --

Acked-by: Tejun Heo <tj@kernel.org> Thanks. -- tejun --

milliseconds of stalls is definitely excessive under a non-preempt kernel - and you have up to 500 msecs of stalls, right? The simplest way you can fix such latencies is to look at the function trace, figure out which loop in the kernel takes so long to execute, and add a cond_resched() call to it. [there are other situations where a more complicated fix is needed, but this seems like a simpler scenario.] Ingo --

From: Herbert Xu <herbert@gondor.apana.org.au> That's another option, of course. And crypto could use remote True, but old hardware will always exist. A lot of very reasonable machines out there will benefit from software RX flow seperation. --

It's non-trivial but possible. I have a test implementation that runs the whole IP layer in parallel. The basic idea to keep track of the packet ordering is to give the packets sequence numbers befor we run in parallel. Befor we push the packets to the upper layers or to the neighboring subsystem I have a mechanism that brings them back to the right order. With my test environment (two quad core boxes) I get with IPSEC aes192-sha1 and one tcp stream a throughput of about 600 Mbit/s compared ...

No, it does not have bluetooth. Chris --

Hey David, can you add an entry to the MAINTAINERs file for Intel IOMMU? I found it difficult to find the responsible person for this thread. Joerg --

OK, here's the time index at which it b0rked: 18:28:38 sum 1106.00 18:28:39 sum 1037.62 18:28:40 sum 1069.00 18:28:41 sum 1167.00 18:28:42 sum 1155.00 18:28:43 sum 1339.00 18:28:44 sum 18355.00 18:28:45 sum 17845.45 18:28:46 sum 15285.00 18:28:47 sum 17511.00 18:28:48 sum 17568.69 18:28:49 sum 17704.04 18:28:50 sum 18566.67 18:28:51 sum ...

Calgary can't use fullflush, but in general the more unified our IOMMU options, the better for the users. It's a pain to have to remember which option applies to which IOMMU implementation. Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 --

This is how it is documented in dmaengine.h: * @slave: data for preparing slave transfer. Must be non-NULL iff the * DMA_SLAVE capability is requested. But, looking at dma_client_chan_alloc() it seems, any client requesting a channel can provide a slave and link it to a specific dma_dev, regardless what capabilities the client is requesting, or am I missing something? If so, then yes, please, let's allow all do this. Wouldn't it be better to As far as I understand, this extension ...

Bernd Eckenfels writes: > In article <18646.39701.819497.337394@harpo.it.uu.se> you wrote: > > Applications that handle SEGV/BUS/ILL/FPE aren't that uncommon. > > JRE uses SIGSEGV for (expected) NullPointers. So you might see a lot of > those on the logs. However: not in all cases you dont want to log handled > (fatal) signals. Not sure how to detect those. Maybe it is better to fix > applications and remove their home grown crash logging. I was referring to applications that ...

Thomas Jarosch writes: > Hello together, > > here's the reworked version of the signal logging patch. > Many thanks to Marcin Slusarz for reviewing it. > > The idea is to briefly log "fatal" signals by default, the output > should be close to zero during normal system operation. > Faulty hardware gets detected much quicker > if you see crashing apps in the logs. > > The patch applies to 2.6.26 and git HEAD. > scripts/checkpatch.pl is happy, too. > > I'm off for a ...

Hi Paul, Some further thoughts about design differences between your and my implementation: - rcutree's qsmaskinit is the worst-case list of cpus that could be in rcu read side critical sections. - rcustate's cpu_total is the accurate list of cpus that could be in rcu read side critical sections. Both variables are read rarely: for rcu_state, twice per grace period. rcutree fixes up cpus that are "incorrectly" listed in qsmaskinit with force_quiescent_state(). It forces rcutree to ...

Am Sonntag, den 31.08.2008, 11:09 -0300 schrieb Luiz Fernando N. I was away the last days, but i notice that the virtualbox update to 2.0.2 solve all problems i mentioned. We also have same responses from other arch users. I never saw the "early boot oops" (this have had gone still with our kernel update, mystical....). But also the "heavy IO oops" has gone. So it was a virtualbox problem, they fixed it in: http://www.virtualbox.org/ticket/1875 So from my side this is ...