Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]
* Andrew Morton <[EMAIL PROTECTED]> wrote: > It's a kmap_atomic() debugging patch which I wrote ages ago and whcih > Ingo sucked into his tree. I don't _think_ this warning is present in > your tree at all. > > http://lkml.org/lkml/2007/11/29/157 is where it starts. > > I had a lenghty back-and-forth with Christoph on this within the past > couple of months and I cannot locate the thread and I don't recall > what the upshot was and Christoph is still offline. > > Knocking out __GFP_ZERO at the point where the slab allocator(s) call > the page allocator seems like a good approach to me. > > But I don't think we need to do anything for 2.6.24.. ok - Rafael, please strike this off the regressions list, there is no problem in .24 other than the double memset for some SLOB metadata. Ingo -- 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/
2.6.24-rc4-mm1: acpi reboots machine
Hi Andrew, Hi Len, after booting 2.6.24-rc4-mm1 (2.6.24-rc4-190-g94545ba, otoh, boots just fine) on my asus laptop, the machine reboots after claiming that "Critical temperature reached (255 C)." However, the degrees number is kinda hinting at 0xff all-ones field. Will try dump_stack in acpi_thermal_critical() to checkout the call path. For now here's the netconsole bootlog: [0.00] Linux version 2.6.24-rc4-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)) #7 SMP PREEMPT Sun Dec 9 08:27:26 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ff4 (usable) [0.00] BIOS-e820: 1ff4 - 1ff5 (ACPI data) [0.00] BIOS-e820: 1ff5 - 2000 (ACPI NVS) [0.00] 511MB LOWMEM available. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 130880 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 130880 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F5DF0, 0014 (r0 ACPIAM) [0.00] ACPI: RSDT 1FF4, 002C (r1 A M I OEMRSDT 6000423 MSFT 97) [0.00] ACPI: FACP 1FF40200, 0081 (r1 A M I OEMFACP 6000423 MSFT 97) [0.00] ACPI: DSDT 1FF40400, 628D (r1 1ABSP 1ABSP0011 MSFT 201) [0.00] ACPI: FACS 1FF5, 0040 [0.00] ACPI: OEMB 1FF50040, 0053 (r1 A M I OEMBIOS 6000423 MSFT 97) [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] Allocating PCI resources starting at 3000 (gap: 2000:e000) [0.00] swsusp: Registered nosave memory region: 0009f000 - 000a [0.00] swsusp: Registered nosave memory region: 000a - 000e [0.00] swsusp: Registered nosave memory region: 000e - 0010 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129475 [0.00] Kernel command line: root=/dev/hda1 vga=0 nmi_watchdog=1 [EMAIL PROTECTED]/,@192.168.45.26/ [0.00] Found and enabled local APIC! [0.00] Enabling fast FPU save and restore... done. [0.00] Enabling unmasked SIMD FPU exception support... done. [0.00] Initializing CPU#0 [0.00] CPU 0 irqstacks, hard=c0451000 soft=c0449000 [0.00] PID hash table entries: 2048 (order: 11, 8192 bytes) [0.00] Detected 1500.114 MHz processor. [ 50.138075] Console: colour VGA+ 80x25 [ 50.138080] console [tty0] enabled [ 50.140479] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 50.140882] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 50.160065] Memory: 513364k/523520k available (2049k kernel code, 9712k reserved, 1113k data, 172k init, 0k highmem) [ 50.160147] virtual kernel memory layout: [ 50.160148] fixmap : 0xfffb5000 - 0xf000 ( 296 kB) [ 50.160150] vmalloc : 0xe080 - 0xfffb3000 ( 503 MB) [ 50.160151] lowmem : 0xc000 - 0xdff4 ( 511 MB) [ 50.160153] .init : 0xc041b000 - 0xc0446000 ( 172 kB) [ 50.160154] .data : 0xc030067f - 0xc0416ca8 (1113 kB) [ 50.160156] .text : 0xc010 - 0xc030067f (2049 kB) [ 50.160549] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 50.160705] SLUB: Genslabs=11, HWalign=64, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 [ 50.220728] Calibrating delay using timer specific routine.. 3003.73 BogoMIPS (lpj=1501865) [ 50.220857] Security Framework initialized [ 50.220934] Mount-cache hash table entries: 512 [ 50.221174] CPU: L1 I cache: 32K, L1 D cache: 32K [ 50.221273] CPU: L2 cache: 1024K [ 50.221338] Intel machine check architecture supported. [ 50.221398] Intel machine check reporting enabled on CPU#0. [ 50.221459] Compat vDSO mapped to e000. [ 50.221524] Checking 'hlt' instruction... OK. [ 50.225022] SMP alternatives: switching to UP code [ 50.225766] Freeing SMP alternatives: 11k freed [ 50.225823] ACPI: Core revision 20070126 [ 50.229623] ACPI: setting ELCR to 0200 (from 0c30) [ 50.734915] CPU0: Intel(R) Pentium(R) M processor 1500MHz stepping 05 [ 50.735059] SMP motherboard not detected. [ 50.836119] Brought up 1 CPUs [ 50.836305] khelper used greatest stack depth: 3352 bytes left [ 50.836463] net_namespace: 108 bytes [ 50.837167] NET: Registered protocol family 16 [ 50.837466] ACPI: bus type pci registered [ 50.838812] PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2 [ 50.838872] PCI: Using configuration type 1 [ 50.838928] Setting up standard PCI
Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
* Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> > i'm wondering why it had no effect now
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index e0d3a4f..a46c252 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -47,15 +47,21 @@ void __init cpu_hotplug_init(void)
> }
>
> #ifdef CONFIG_HOTPLUG_CPU
> -
> +#include
> void get_online_cpus(void)
> {
> + outb(0x20, 0x80);
> might_sleep();
> + outb(0x21, 0x80);
ah. If you comment out get_online_cpus()/put_online_cpus() from
kernel/softlockup.c, does it start working?
Gautham, any ideas?
Ingo
--
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: usb regression in 2.6.24-rc4
Gene Heskett wrote: > Greetings guys & gals; Hi , > > This was sent about an hour ago to the usb-devel list also. > - > Just a few minutes ago I needed to make use of my scanner, an Epson 1250u. > > Firing up xsane, the usual select the device menu window didn't show, and it > went straight to my tv card as the only input device. > > I couldn't recall the name of the tool that scans for scanners that's in the > sane package, or should be, so I then did an lsusb, but got an empty result! > > Unplugging the usb cable from the scanner, then reconnecting the usb cable > got > me the usual disconnect and connect messages in the log, but xsane still > couldn't find it. > > So I rebooted to 2.6.24-rc4 again, same result. lsusb still gave an empty > result. The two kernels were generated from the same .config as far as I > know. The -rc3 .config was fed to a "make oldconfig" to make > the -rc4 .config as is the usual practice. > > So I then rebooted to 2.6.24-rc3, and it all works again. I got the scanning > done and the pix sent on their merry way. > > Anybody have a suggestion of what to check, or maybe a patch to revert? Or > a .config option that needs to be enabled? > Sounds for me like this one : http://lkml.org/lkml/2007/12/6/409 Gabriel -- 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: Please revert: PCI: fix IDE legacy mode resources
On Sun, 2007-12-09 at 02:12 +, Ralf Baechle wrote: > So where do we stand with this? > > As I understand the Cobalt system controller it is not possible to address > ioport addresses below 0x1000 at all on the PCI bus of the GT-64111. > As such I think the best solution is a GT-64111-specific PCI fixup to > clear out legacy resources. The IDE controller in the VIA VT82C586 could > then be used only by its normal that is non-legacy address and > commit fd6e732186ab522c812ab19c2c5e5befb8ec8115 could be reverted and PPC > would be happy too? If that is the case though (that is it can't issue low ioport cycles), how would have the fd6e7321... worked in the first place ? Hrm... strange. My understanding is that all that patch does is put junk in the pci_dev resource structures :-) Maybe that's enough to cause the PCI layer later on to be unhappy about them and reassign the BARs to some place that works ? In which case, you are right, a better approach is a quirk on this specific platform, or even better, mark 0...0x1000 busy in ioport_resources and let the generic code clash & re-assign... I must admit I'm a bit confused tho... Anyway, so far, nobody is arguing in favor of keeping this patch in nor so far trying and explanation on why it wouldn't be totally bogus, so I suggest we revert it :-) Cheers, Ben. -- 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] pci: Fix bus resource assignment on 32 bits with 64b resources
On Thu, 2007-12-06 at 17:00 -0800, Greg KH wrote: > But that is how we already handle this today, in numerous places in > the > kernel for this very type. > > So, you can disagree that this is what we need to do, and if so, feel > free to fix up a whole lot of files in the tree :) Heh, ok, allright, I'll respin with the casts. Cheers, Ben. -- 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 3/6] random: do extraction before mixing
On Sat, Dec 08, 2007 at 07:35:54PM -0500, Theodore Tso wrote:
> On Sat, Dec 08, 2007 at 05:20:17PM -0600, Matt Mackall wrote:
> > random: do extraction before mixing
> >
> > If an attacker manages to capture the current pool state, she can
> > determine the last 10 bytes extracted from the pool.
>
> That's not true; we aren't just extracting data in the
> __add_entropy_words() call. In fact, above that, the bulk of the
> extraction comes form when we hash the entire pool, feeding back a
> portion of the hash into the pool here:
>
> for (i = 0; i < r->poolinfo->poolwords; i += 16) {
> /* hash blocks of 16 words = 512 bits */
> sha_transform(buf, (__u8 *)(r->pool + i), buf + 5);
> /* feed back portion of the resulting hash */
> add_entropy_words(r, [i % 5], 1);
> }
Ok, yes, I'd forgotten we were chaining in the final sha_transform. I
plead too many bufs and buf+5s, which I fix up in 6/6. Funny thing is
that I'd convinced myself that this attack didn't work (correct) last
year when I read the paper I mentioned earlier. But yesterday and
today I couldn't spot the problem with it. So again, I'll add an
explicit comment for future hackers and researchers.
--
Mathematics is the supreme nostalgia of our time.
--
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.24-rc4-git5: Reported regressions from 2.6.23
Hello, (cc'ing Alan) Andrew Morton wrote: >> Subject : cd/dvd inaccessible in 2.6.24-rc2 >> Submitter: Will Trives <[EMAIL PROTECTED]> >> References : http://lkml.org/lkml/2007/11/9/290 >>http://bugzilla.kernel.org/show_bug.cgi?id=9346 >> Handled-By : Len Brown <[EMAIL PROTECTED]> >>Tejun Heo <[EMAIL PROTECTED]> >> Patch: >> > > Nasty one. Tejun and several diligent reporters are doing sterling > work there and things have improved. I don't know whether any of > Tejun's patches have been merged yet, but we'll probably be OK on > this one. I'm still trying to find out what's really going on. That drive is quite peculiar. > What is unclear (to me) is what actually caused those people's machines to > break? It's introduced by setting ATAPI transfer chunk size to actual transfer size which is the right thing to do generally. However, with the change, the ATAPI HSM should be ready to drain full extra transfer chunks which libata HSM wasn't doing. With that part changed, most regressions should go away. Unfortunately, simply adding that doesn't fix the case in bug 9346 and I'm still trying to find out why. The good news is that the drive works fine with proposed more extensive improvements to libata ATAPI which will probably be included into 2.6.25, so we at least have long term solution. If we fail to find out the solution in time, we always have the alternative of backing out the ATAPI transfer chunk size update. This will break some other cases which were fixed by the change but those won't be regressions at least and we can add transfer chunk size update with other changes to 2.6.25. Thanks. -- tejun -- 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] swap image signature check upon resume
On Sat, Dec 08, 2007 at 11:50:33PM +0100, Rafael J. Wysocki wrote: > On Saturday, 8 of December 2007, Borislav Petkov wrote: > > On Fri, Dec 07, 2007 at 09:19:09PM +0100, Rafael J. Wysocki wrote: > > > > ... > > > > > > > Well, there's a patchset in the current mainline that allows you to > > > > > use > > > > > arbitrary (sufficiently new) kernel to load the image and then > > > > > restore the > > > > > image kernel. So, you can hibernate 2.6.24-rc3 and use 2.6.24-rc2 to > > > > > restore > > > > > it, for example. > > > > > > > > > > I'm going to do that for i386 too. > > > > right, this is d307c4a8e826c44f9633bd3f7e60d0491e7d885a (Hibernation: > > > > Arbitrary > > > > boot kernel support - generic code), i should've seen that. What's the > > > > status of > > > > those bits, from a quick scan it seems they need some rewiring > > > > (Kconfig, e.g. > > > > CONFIG_ARCH_HIBERNATION_HEADER etc..) and arch-specific save and restore > > > > functions? > > > > > > No, this code is fully functional. :-) > > > > > > The arch save and restore functions are in arch/x86/kernel/suspend_64.c . > > > > > > As I said, i386 is not yet supported. > > > > nice, holler if you need a tester when you have some prototypes ready. By > > the way, > > what do you do when the suspend image header mismatches and it is unsafe to > > continue booting? > > If the image header doesn't match, we don't load it and return an error code, > which usually results in the boot kernel continuing to boot. But if you continue to boot the filesystems were still mounted and fsck has to go over them and check for errors. In the case of ext2 this takes relatively long depending on the size of the partition. However, this is only the smaller problem, the problem of data loss is what worries me. Instead, I'd rather issue a warning that the swsusp header mismatches, say with which kernel the machine got suspended with and then start the countdown for reboot. Thoughts? -- Regards/Gruß, Boris. -- 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: Why does reading from /dev/urandom deplete entropy so much?
On Sun, 2007-12-09 at 06:21 +0100, Willy Tarreau wrote: > Wouldn't it be possible to mix the data with the pid+uid of the reading > process so that even if another one tries to collect data from urandom, > he cannot predict what another process will get ? BTW, I think that the > tuple (pid,uid,timestamp of open) is unpredictable and uncontrollable > enough to provide one or even a few bits of entropy by itself. Timestamp perhaps, but pid/uid are trivially guessable in automated environments, such as LiveCDs. And if you're also running on an embedded system without a RTC (common, folks like to save a few cents) then it's all pretty much "trivially" guessable on some level. Jon. -- 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.24-rc4-git5: Reported regressions from 2.6.23
Hello, Andrew Morton wrote: >> Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is >> beyond end of object >> Submitter: Hans de Bruin <[EMAIL PROTECTED]> >> References : http://bugzilla.kernel.org/show_bug.cgi?id=9320 >> Handled-By : Robert Moore <[EMAIL PROTECTED]> >>Tejun Heo <[EMAIL PROTECTED]> >>Fu Michael <[EMAIL PROTECTED]> >> Patch: >> > > A number of other people are seeing the same thing and Tejun is > putting in a blacklist of machines which cannot use libata+acpi. > That patch is not yet in any git tree which I pull. > > AFACIT the machines kepe working OK - there's just some nasty dmesg > spew. > > If any machines _are_ breaking then this could cause real problems > and I'd prefer that we either go for a whitelist or arrange to > detect the condition and fall back to non-acpi ata. The pending patchset should make ATA ACPI quite resistant to failures. Known bad boards can be blacklisted (currently only one is on the list), ATA ACPI is disabled quicker if ACPI evalution fails, execution errors are handled better and commands which are intended to help the vendor instead of the user are filtered. So, I think we have enough safety nets. Thanks. -- tejun -- 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: laptop reboots right after hibernation
Kjartan Maraas wrote:
> to., 06.12.2007 kl. 11.38 +0900, skrev Tejun Heo:
>> Thanks. Almost there. Can you please try the attached two patches and
>> report the boot log?
>>
> Here we go again.
Hmmm... Ah.. okay. Wrongly splitted patch. Can you please do it one
more time?
Thanks.
--
tejun
Index: work/include/linux/libata.h
===
--- work.orig/include/linux/libata.h
+++ work/include/linux/libata.h
@@ -1013,18 +1013,18 @@ extern void ata_do_eh(struct ata_port *a
* printk helpers
*/
#define ata_port_printk(ap, lv, fmt, args...) \
- printk(lv"ata%u: "fmt, (ap)->print_id , ##args)
+ printk("%sata%u: "fmt, lv, (ap)->print_id , ##args)
#define ata_link_printk(link, lv, fmt, args...) do { \
if ((link)->ap->nr_pmp_links) \
- printk(lv"ata%u.%02u: "fmt, (link)->ap->print_id, \
+ printk("%sata%u.%02u: "fmt, lv, (link)->ap->print_id, \
(link)->pmp , ##args); \
else \
- printk(lv"ata%u: "fmt, (link)->ap->print_id , ##args); \
+ printk("%sata%u: "fmt, lv, (link)->ap->print_id , ##args); \
} while(0)
#define ata_dev_printk(dev, lv, fmt, args...) \
- printk(lv"ata%u.%02u: "fmt, (dev)->link->ap->print_id, \
+ printk("%sata%u.%02u: "fmt, lv, (dev)->link->ap->print_id, \
(dev)->link->pmp + (dev)->devno , ##args)
/*
Index: work/include/linux/ata.h
===
--- work.orig/include/linux/ata.h
+++ work/include/linux/ata.h
@@ -190,6 +190,8 @@ enum {
ATA_CMD_READ_LOG_EXT = 0x2f,
ATA_CMD_PMP_READ = 0xE4,
ATA_CMD_PMP_WRITE = 0xE8,
+ ATA_CMD_CONF_OVERLAY = 0xB1,
+ ATA_CMD_SEC_FREEZE_LOCK = 0xF5,
/* READ_LOG_EXT pages */
ATA_LOG_SATA_NCQ = 0x10,
@@ -239,6 +241,19 @@ enum {
SATA_AN = 0x05, /* Asynchronous Notification */
SATA_DIPM = 0x03, /* Device Initiated Power Management */
+ /* feature values for SET_MAX */
+ ATA_SET_MAX_ADDR = 0x00,
+ ATA_SET_MAX_PASSWD = 0x01,
+ ATA_SET_MAX_LOCK = 0x02,
+ ATA_SET_MAX_UNLOCK = 0x03,
+ ATA_SET_MAX_FREEZE_LOCK = 0x04,
+
+ /* feature values for DEVICE CONFIGURATION OVERLAY */
+ ATA_DCO_RESTORE = 0xC0,
+ ATA_DCO_FREEZE_LOCK = 0xC1,
+ ATA_DCO_IDENTIFY = 0xC2,
+ ATA_DCO_SET = 0xC3,
+
/* ATAPI stuff */
ATAPI_PKT_DMA = (1 << 0),
ATAPI_DMADIR = (1 << 2), /* ATAPI data dir:
Index: work/drivers/ata/libata-acpi.c
===
--- work.orig/drivers/ata/libata-acpi.c
+++ work/drivers/ata/libata-acpi.c
@@ -311,8 +311,8 @@ EXPORT_SYMBOL_GPL(ata_acpi_stm);
* EH context.
*
* RETURNS:
- * Number of taskfiles on success, 0 if _GTF doesn't exist or doesn't
- * contain valid data.
+ * Number of taskfiles on success, 0 if _GTF doesn't exist. -EINVAL
+ * if _GTF is invalid.
*/
static int ata_dev_get_GTF(struct ata_device *dev, struct ata_acpi_gtf **gtf,
void **ptr_to_free)
@@ -339,6 +339,7 @@ static int ata_dev_get_GTF(struct ata_de
ata_dev_printk(dev, KERN_WARNING,
"_GTF evaluation failed (AE 0x%x)\n",
status);
+ rc = -EINVAL;
}
goto out_free;
}
@@ -350,6 +351,7 @@ static int ata_dev_get_GTF(struct ata_de
__FUNCTION__,
(unsigned long long)output.length,
output.pointer);
+ rc = -EINVAL;
goto out_free;
}
@@ -358,6 +360,7 @@ static int ata_dev_get_GTF(struct ata_de
ata_dev_printk(dev, KERN_WARNING,
"_GTF unexpected object type 0x%x\n",
out_obj->type);
+ rc = -EINVAL;
goto out_free;
}
@@ -365,6 +368,7 @@ static int ata_dev_get_GTF(struct ata_de
ata_dev_printk(dev, KERN_WARNING,
"unexpected _GTF length (%d)\n",
out_obj->buffer.length);
+ rc = -EINVAL;
goto out_free;
}
@@ -397,7 +401,7 @@ int ata_acpi_cbl_80wire(struct ata_port
int valid = 0;
/* No _GTM data, no information */
- if (ata_acpi_gtm(ap, ) < 0)
+ if (!ap->acpi_handle || ata_acpi_gtm(ap, ) < 0)
return 0;
/* Split timing, DMA enabled */
@@ -422,7 +426,7 @@ int ata_acpi_cbl_80wire(struct ata_port
EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
/**
- * taskfile_load_raw - send taskfile registers to host controller
+ * ata_acpi_run_tf - send taskfile registers to host controller
* @dev: target ATA device
* @gtf: raw ATA taskfile register set (0x1f1 - 0x1f7)
*
@@ -441,14 +445,17 @@ EXPORT_SYMBOL_GPL(ata_acpi_cbl_80wire);
* EH context.
*
* RETURNS:
- * 0 on success, -errno on failure.
+ * 1 if command is executed successfully. 0 if ignored or rejected,
+ * -errno on other errors.
*/
-static int taskfile_load_raw(struct ata_device *dev,
- const struct ata_acpi_gtf *gtf)
+static int ata_acpi_run_tf(struct ata_device *dev,
+ const struct ata_acpi_gtf *gtf)
{
- struct ata_port *ap = dev->link->ap;
struct ata_taskfile tf, rtf;
unsigned int err_mask;
+ const char *level;
+ char msg[60];
+ int rc;
if ((gtf->tf[0] == 0) && (gtf->tf[1] == 0) && (gtf->tf[2] == 0)
&& (gtf->tf[3] == 0) && (gtf->tf[4] == 0) && (gtf->tf[5] == 0)
@@
Re: Correct types for mod_devicetable.h (was: Re: m68k build failure)
On Sat, 2007-12-08 at 22:58 +0100, Adrian Bunk wrote: > On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote: > > On Sunday 02 December 2007 22:22:31 Geert Uytterhoeven wrote: > > > On Sat, 1 Dec 2007, Pierre Ossman wrote: > > > > Yeah, that could work. Have a header with stuff like this: > > > > > > > > typedef u16 __attribute__((aligned(2))) aligned_u16; > > > > typedef u32 __attribute__((aligned(4))) aligned_u32; > > > > > > I gave it a try: > > > > This seems to turn a molehill into a mountain. > > > > We can change that mod_devicetable.h at any time; it's not supposed to be a > > userspace API (the kernel build system doesn't count). > > module-init-tools is userspace and not shipped as part of the kernel > build system... Not really an issue, so long as I get a head's up, but we'll force users to upgrade so let's be sure we want to do this/everyone's happy. Jon. -- 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: usb regression in 2.6.24-rc4
Hi. Just a quick reply. Is /proc/bus/usb empty? Is there no symlink named devices (and so you can't cat devices to see what is there)? Also, (if /proc/bus/usb is empty), is /dev/bus/usb/devices not empty? (When you cat devices does it list usb devices you have plugged in?) If so, then that's the problem I'm having. Its very similar to yours, xsane points to the tv card only (not the scanner). Something went away with the recent kernel. Bob -- 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: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 01:46:12 tarihinde Theodore Tso şunları yazmıştı: > On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote: > > > As long as /dev/random is readable for all users there's no reason to > > > use /dev/urandom for a local DoS... > > > > Draining entropy in /dev/urandom means that insecure and possibly not > > random data will be used and well thats a security bug if not a DoS bug. > > Actually in modern 2.6 kernels there are two separate output entropy > pools for /dev/random and /dev/urandom. So assuming that the > adversary doesn't know the contents of the current state of the > entropy pool (i.e., the RNG is well seeded with entropy), you can read > all you want from /dev/urandom and that won't give an adversary > successful information to attack /dev/random. My understanding was if you can drain entropy from /dev/urandom any futher reads from /dev/urandom will result in data which is not random at all. Is that wrong? Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- 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/
usb regression in 2.6.24-rc4
Greetings guys & gals; This was sent about an hour ago to the usb-devel list also. - Just a few minutes ago I needed to make use of my scanner, an Epson 1250u. Firing up xsane, the usual select the device menu window didn't show, and it went straight to my tv card as the only input device. I couldn't recall the name of the tool that scans for scanners that's in the sane package, or should be, so I then did an lsusb, but got an empty result! Unplugging the usb cable from the scanner, then reconnecting the usb cable got me the usual disconnect and connect messages in the log, but xsane still couldn't find it. So I rebooted to 2.6.24-rc4 again, same result. lsusb still gave an empty result. The two kernels were generated from the same .config as far as I know. The -rc3 .config was fed to a "make oldconfig" to make the -rc4 .config as is the usual practice. So I then rebooted to 2.6.24-rc3, and it all works again. I got the scanning done and the pix sent on their merry way. Anybody have a suggestion of what to check, or maybe a patch to revert? Or a .config option that needs to be enabled? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Nothing is impossible for the man who doesn't have to do it himself. -- A.H. Weiler -- 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.24-rc4-git5: Reported regressions from 2.6.23
Robert Hancock wrote: > Matthew Garrett wrote: >> On Sat, Dec 08, 2007 at 02:20:01AM -0800, Andrew Morton wrote: >>> On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote: ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (0) is beyond end of object [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.GTF_] (Node c180b990), AE_AML_PACKAGE_LIMIT ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.IDE0.CHN0.DRV1._GTF] (Node c180b888), AE_AML_PACKAGE_LIMIT ata1.01: _GTF evaluation failed (AE 0x300d) >> >> 037f6bb79f753c014bc84bca0de9bf98bb5ab169 ought to have fixed this? >> > > I should think it should have. > > I think we're too aggressive about disabling the libata ACPI support, > even. One of my laptop's _GTF commands on resume is a DEVICE > CONFIGURATION FREEZE LOCK command, which gets rejected by the drive > (maybe it worked on the original Hitachi disk, but I've upgraded it to a > newer Samsung). I'd say if the drive returns command aborted on one of > these, we should just ignore that command and continue to the next one > without trying to retry or disabling the ACPI support entirely. Yeap, my pending patchset does exactly that. It's currently being tested by but reporters. I'll soon post the patchset. Thanks. -- tejun -- 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] depmod: sort output according to modules.order
Jon Masters wrote: > On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: > >> Kbuild now generates and installs modules.order along with modules. >> This patch updates depmod such that it sorts module list according to >> the file before generating output files. Modules which aren't on >> modules.order are put after modules which are ordered by >> modules.order. > > Thanks. Please CC me in general on these patches :-) Sure. FYI, updated patchset is posted. http://thread.gmane.org/gmane.linux.kernel/611212 -- tejun -- 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] kbuild: implement modules.order
Adrian Bunk wrote: > And thinking about it, it doesn't seem to add any problems regarding > what I have in mind: > > If we would ever stop having any well-defined link-order for in-kernel > code and express everything through initcall levels, we simply must > additionally update the modules.order file. Expressing order in Makefile is a convenient way to express simple ordering. I think it's nice to keep it that way even if it doesn't necessarily mean link order. So, maybe we can do the reverse and make built in modules follow module order regardless of actual link order (say sort init table according to module order before final link). Thanks. -- tejun -- 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 4/6] random: make backtracking attacks harder
On Sat, Dec 08, 2007 at 08:45:50PM -0500, Theodore Tso wrote: > On Sat, Dec 08, 2007 at 05:20:38PM -0600, Matt Mackall wrote: > > random: make backtracking attacks harder > > > > At each extraction, we change (poolbits / 16) + 32 bits in the pool, > > or 96 bits in the case of the secondary pools. Thus, a brute-force > > backtracking attack on the pool state is less difficult than breaking > > the hash. In certain cases, this difficulty may be is reduced to 2^64 > > iterations. > > OK, a backtracking attack assumes a fairly catastrophic case where the > attacker has managed to compromise the internal pool state. In Linux, > if an attacker has this much access, in most scenarios the attacker > probably has the ability to gain write access to kernel memory as > well, at which point you have far worse problems. > > The definition of a backtracking attack is when the attacker uses the > current pool state to try to recover the last entropy extraction. As > you point out, at each extraction, 96 bits are changed in the pool. > But at each extraction, only 80 bits are extracted. Agreed. > If you are trying to find the value of the 80 bits that were > extracted, and you know the current state of the pool, yes, you can > take the 96 bits that were changed after the last extraction, and try > all possible 2**96 combinations of the bits; but you probably won't > rule anything out, since after you iterate over all of the 2**96 > combinations, you'll probably be able to generate all of the 2**80 > possible output bits. So you won't gain anything by trying to do a > backtracking attack. So I don't think there's anything to worry about > here. Two observations: - 2**96 << 2**160 so our feedback is much weaker than our hash so we should improve it on general principle - there's a way to improve this attack to 2**64 in some situations! I presume you've seen this paper: http://eprint.iacr.org/2006/086.pdf It was fairly obsolete at printing and makes a bunch of mistakes. But they do observe that at certain points in our feedback, the first 512-bit block of the pool is not overwritten by the feedback and thus 32 bits of feedback can be immediately discovered. Then an attacker can run 2**64 hashes to recover the remaining bits with excellent odds of having a unique preimage. It can't usually be extended multiple iterations because we move the add_ptr too much, so it's fairly weak as a backtracking attack. They precede this with a more general description of a 2**96 attack which doesn't work for precisely the reason you describe (2**16 possible preimages for each output). But their 2**64 attack does seem like it works (in the world of cryptanalysis, and not real hardware of course!). Simply feeding back all five words of our hash rather than three in the secondary pools hardens this all right up. This patch also makes everything in here much easier to read and analyze. > What you describe in your comments: > > > +* We mix the hash back into the pool to prevent backtracking > > +* attacks (where the attacker knows the state of the pool > > +* plus the current outputs, and attempts to find previous > > +* ouputs), unless the hash function can be inverted. That part of the comment is not new, but I don't remember which of us wrote it.. > > ...By > > +* mixing at least a SHA1 worth of hash data back, we make > > +* brute-forcing the feedback as hard as brute-forcing the > > +* hash. > > */ That part is new and I think is accurate. > Secondly, the fact that we use catastrophic reseeding means that even > if the state was compromised, at some point in time, every so often > when we do a "catastrophic reseed", this acts as a firewall to limit > the damage caused by a internal state exposure, both in the past and > the future. Absolutely. Having some depth in the design is quite valuable. But that doesn't mean we shouldn't shore up individual weaknesses when we find them. -- Mathematics is the supreme nostalgia of our time. -- 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: Why does reading from /dev/urandom deplete entropy so much?
On Sat, Dec 08, 2007 at 06:46:12PM -0500, Theodore Tso wrote: > On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote: > > > As long as /dev/random is readable for all users there's no reason to > > > use /dev/urandom for a local DoS... > > > > Draining entropy in /dev/urandom means that insecure and possibly not > > random > > data will be used and well thats a security bug if not a DoS bug. > > Actually in modern 2.6 kernels there are two separate output entropy > pools for /dev/random and /dev/urandom. So assuming that the > adversary doesn't know the contents of the current state of the > entropy pool (i.e., the RNG is well seeded with entropy), you can read > all you want from /dev/urandom and that won't give an adversary > successful information to attack /dev/random. Wouldn't it be possible to mix the data with the pid+uid of the reading process so that even if another one tries to collect data from urandom, he cannot predict what another process will get ? BTW, I think that the tuple (pid,uid,timestamp of open) is unpredictable and uncontrollable enough to provide one or even a few bits of entropy by itself. Regards, Willy -- 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 6/6] random: improve variable naming, clear extract buffer
On Sat, Dec 08, 2007 at 08:51:54PM -0500, Theodore Tso wrote: > On Sat, Dec 08, 2007 at 05:21:00PM -0600, Matt Mackall wrote: > > random: improve variable naming, clear extract buffer > > > > - split the SHA variables apart into hash and workspace > > - rename data to extract > > - wipe extract and workspace after hashing > > > > diff -r 924f9a441236 drivers/char/random.c > > --- a/drivers/char/random.c Sat Dec 08 16:22:29 2007 -0600 > > +++ b/drivers/char/random.c Sat Dec 08 16:32:31 2007 -0600 > > @@ -461,7 +461,7 @@ static void __add_entropy_words(struct e > > unsigned long flags; > > /* rotate the add pointer more rapidly to span more of the > > * pool on a given add */ > > - const int step = 5; > > + const int step = 13; > > > > /* Taps are constant, so we can load them without holding r->lock. */ > > tap1 = r->poolinfo->tap1; > > This change has nothing to do with the patch comment. If you want to > change the step size from 5 to 13, why not just change patch 5/6 to > just use a step size of 13 from the beginning? Patch refresh gone wrong. > Otherwise, yeah, this patch does make sense. Twice, in fact. This patch as sent won't compile due to an extra &. -- Mathematics is the supreme nostalgia of our time. -- 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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
On 08-12-07 20:25, David P. Reed wrote: In any case, my machine does not have an ISA bus. Why should it? It's a laptop! A bus is not something with expansion slots. Your machine has an ISA bus, or LPC rather, if only to hang its BIOS of. That earlier report about BIOS chips shitting themselves due to aborts on LPC together with ACPI involving the BIOS sounds a bit suspicious (and in that case using 0xed shouldn't help any). Rene. -- 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/
sparsemem: Make SPARSEMEM_VMEMMAP selectable
From: Geoff Levand <[EMAIL PROTECTED]> SPARSEMEM_VMEMMAP needs to be a selectable config option to support building the kernel both with and without sparsemem vmemmap support. This selection is desirable for platforms which could be configured one way for platform specific builds and the other for multi-platform builds. Signed-off-by: Miguel Botón <[EMAIL PROTECTED]> Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- Andrew, Please consider for 2.6.24. -Geoff mm/Kconfig | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) --- a/mm/Kconfig +++ b/mm/Kconfig @@ -112,18 +112,17 @@ config SPARSEMEM_EXTREME def_bool y depends on SPARSEMEM && !SPARSEMEM_STATIC -# -# SPARSEMEM_VMEMMAP uses a virtually mapped mem_map to optimise pfn_to_page -# and page_to_pfn. The most efficient option where kernel virtual space is -# not under pressure. -# config SPARSEMEM_VMEMMAP_ENABLE def_bool n config SPARSEMEM_VMEMMAP - bool - depends on SPARSEMEM - default y if (SPARSEMEM_VMEMMAP_ENABLE) + bool "Sparse Memory virtual memmap" + depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE + default y + help +SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise +pfn_to_page and page_to_pfn operations. This is the most +efficient option when sufficient kernel resources are available. # eventually, we can have this option just 'select SPARSEMEM' config MEMORY_HOTPLUG -- 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 5/6] random: step more rapidly through the pool when adding and extracting
On Sat, Dec 08, 2007 at 08:00:55PM -0800, Andrew Morton wrote: > On Sat, 8 Dec 2007 20:48:20 -0500 Theodore Tso <[EMAIL PROTECTED]> wrote: > > > On Sat, Dec 08, 2007 at 05:20:39PM -0600, Matt Mackall wrote: > > > random: step more rapidly through the pool when adding and extracting > > > > > > Second, this patch spreads the mixing across the pool more rapidly by > > > using a larger step. For our secondary pools, we'll be sure to touch > > > both blocks with each mix, and for our primary pool, we'll change 5 of > > > 8 blocks. > > > > Yeah, that's a good idea. > > > > Acked-by: "Theodore Ts'o" <[EMAIL PROTECTED]> > > > > I cannot find the emails to which you are replying. Not in inbox, not on > lkml, not in spam folders. And lkml.org records your emails and not the > emails to which you are replying. > > I think something went wrong with Matt's outgoing. It did. My laptop didn't relay them through my smarthost and my domain has an SPF record. -- Mathematics is the supreme nostalgia of our time. -- 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: rq_for_each_bio
On Sunday December 9, [EMAIL PROTECTED] wrote: > I have tried to search through the mailing list and it is not entirely > clear, but it looks like this has gone from the kernel: not least > because my driver reports: > > drivers/sh/gdrom/gdrom.c:665: error: implicit declaration of function > 'rq_for_each_bio' > > I am not arguing for a stable ABI/API, I get that one - but is there a > canonical source of changes in the kernel (because unless you cross > reference lkml and git repos the mailing list isn't) and if there is - > how can we get it on the first page of google? :) The canonical source for changes in the kernel is the git history. It stores all of them! The canonical source for changes in the kernel that are important to your driver is the output of the compiler. If the compiler triggers and error where previously it didn't, then you depend on a part of the kernel that has changed --- if someone makes an API change that does not cause a compiler error for people who depend on the old behaviour, then they have done the wrong thing, but that happens rarely. If you get a compiler error, you then look in the git history to find out when the API changed, and read the comment. in this case it is commit 5705f7021748a69d84d6567e68e8851dab551464 If you look at this commit, you will see a brief explanation of the change, and examples of how new code replaced the old. > > (Actually, forget the theologocal discussion, tell me about rq_for_each_bio) Every instance in the kernel of rq_for_each_bio used the bio simply to call bio_for_each_segment. So we discarded rq_for_each_bio and introduced rq_for_each_segment. It make code cleaner (less indent depth) and means that we can make changes to the rules for iterating through segments in a request in just one central place. i.e. we have a higher level of abstraction. If you have a usage of rq_for_each_bio where rq_for_each_segment cannot be used, please show us. NeilBrown -- 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: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Michael Cree wrote: > Kay Sievers wrote: > > On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote: > >> Kay Sievers wrote: > >>> Is the udev daemon (still) running while it fails? > >> Yes, and there's something else I forgot to mention that may be > >> significant... For the bad case, in addition to udevd, "ps -ef" > >> shows a "sh -e /lib/udev/net.agent" running with a PPID of 1. This > >> process doesn't exit until I reboot. If this is normal under the > >> circumstances, please disregard. > > > > Does SysRq-T show where it hangs? > > Ummm... No. I didn't have the CONFIG_MAGIC_SYSRQ flag set, so I set it, > and recompiled the kernel. Guess what - now the system comes up > normally without any problem. The block devices appear in /dev. To > recap: without CONFIG_MAGIC_SYSRQ on the 2.6.24-rc3 kernel the missing > block devices error in /dev occurs and the init scripts fall over on > startup, and with CONFIG_MAGIC_SYSRQ the system comes up normally. I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my machine starts working again if I disable it? Sheesh... The "kernel alignment issue" theory is making sense... We change the size of an initialized variable with the patch, and the problem shows up. We shift starting addresses a different way by tweaking kernel options, and two wrongs make a right? I've seen it happen, and tracking this down isn't going to be easy. Anyone want to wade through the different System.map files and hazard a guess where we're leaving the rails? Here's a very brief diff excerpt between the System.map files corresponding to "sysctl_check patch reverted" (the -dirty version) and "with sysctl_check patch". At least they agree up to line 10870 :-) ... --- /boot/System.map-2.6.24-rc2-g6f37ac79-dirty 2007-12-07 08:03:50.0 -0 600 +++ System.map 2007-12-07 13:43:37.0 -0600 @@ -10868,9414 +10868,9414 @@ fc684b00 R kallsyms_markers fc684d00 R kallsyms_token_table fc685100 R kallsyms_token_index -fc6f61e0 r __pci_fixup_PCI_VENDOR_ID_SERVERWORKSPCI_DEVICE_ID_SERVERWORKS_CSB5IDEquirk_svwks_csb5ide -fc6f61e0 R __start_pci_fixups_early -fc6f61f0 r __pci_fixup_PCI_VENDOR_ID_INTELPCI_DEVICE_ID_INTEL_82801CA_10quirk_ide_samemode (...) -fc716120 r __param_bic_scale -fc716148 r __param_tcp_friendliness -fc716170 R __end_rodata -fc716170 R __stop___param +fc6f61f0 r __pci_fixup_PCI_VENDOR_ID_SERVERWORKSPCI_DEVICE_ID_SERVERWORKS_CSB5IDEquirk_svwks_csb5ide +fc6f61f0 R __start_pci_fixups_early +fc6f6200 r __pci_fixup_PCI_VENDOR_ID_INTELPCI_DEVICE_ID_INTEL_82801CA_10quirk_ide_samemode (...) +fc716130 r __param_bic_scale +fc716158 r __param_tcp_friendliness +fc716180 R __end_rodata +fc716180 R __stop___param fc718000 A __init_begin fc718000 T _sinittext fc718000 t set_reset_devices > When running the broken kernel udev is running (according to 'ps') and > executing /sbin/udevtrigger manually generates a number of errors of the > form: > > scsi_id[]: scsi_id: unable to access '/block' > > The missing /dev/* entries do not appear. I don't get the errors that Michael is seeing, and udevtrigger seems to be exiting without errors (return code 0). The last part is the same: the missing /dev/* entries do not appear. --Bob T. -- 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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Sat, 08 Dec 2007 20:02:54 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-12-08 at 02:07 -0800, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
> > > > On Fri, 07 Dec 2007 23:09:43 +
> > > > Zan Lynx <[EMAIL PROTECTED]> wrote:
> > > [cut]
> > > > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again,
> > > > > > > but I
> > > > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20
> > > > > > > I got
> > > > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2
> > > > > > > reader.
> [cut]
> > argh. OK. And Linus's current tree is OK, yes?
> >
> > In which case we should be OK for 2.6.24 and I guess we can hope like heck
> > that the dud patch doesn't leak into mainline. Hopefully Alan will get
> > some time to look into it before 2.6.25 opens.
>
> Linus' tree is also broken.
>
> I tried a Linus 2.6.24-rc4 and it acts the same way, with a very slow
> transfer rate.
shit
> I also tried 2.6.24-rc4 with the older not-libata PATA drivers and it is
> broken.
squared.
> dmesg had a line about the CF card detected as hda,
> but /sys/block did not have hda and /dev/hda did not function.
But these drivers did work in earlier kernels, yes? 2.6.20 worked, but
we don't know about intervening kernels.
Can you tell us which version(s)?
> I will try the patches you mentioned
Yes, that won't tell use anything.
> but I think I may also have to
> work backward through kernel versions until I find the last one where
> the PCMCIA hd{a,b,c,d,e} drivers worked.
That would be great - a git-bisect is often ideal.
http://www.kernel.org/doc/local/git-quick.html has details.
--
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 5/6] random: step more rapidly through the pool when adding and extracting
On Sat, 8 Dec 2007 20:48:20 -0500 Theodore Tso <[EMAIL PROTECTED]> wrote: > On Sat, Dec 08, 2007 at 05:20:39PM -0600, Matt Mackall wrote: > > random: step more rapidly through the pool when adding and extracting > > > > Second, this patch spreads the mixing across the pool more rapidly by > > using a larger step. For our secondary pools, we'll be sure to touch > > both blocks with each mix, and for our primary pool, we'll change 5 of > > 8 blocks. > > Yeah, that's a good idea. > > Acked-by: "Theodore Ts'o" <[EMAIL PROTECTED]> > I cannot find the emails to which you are replying. Not in inbox, not on lkml, not in spam folders. And lkml.org records your emails and not the emails to which you are replying. I think something went wrong with Matt's outgoing. -- 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: [Bugme-new] [Bug 9482] New: kernel GPF in 2.6.24 (g09f345da)
On Sat, 8 Dec 2007 16:59:30 -0600 "Jon Nelson" <[EMAIL PROTECTED]> wrote:
> I can confirm that 2.6.24rc4 with the (second) patch works fine.
OK, thanks.
We haven't heard back from Ed yet. I'll sit on this for a few more days.
From: Andrew Morton <[EMAIL PROTECTED]>
Cc: "Ed L. Cashin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/block/aoe/aoeblk.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff -puN
drivers/block/aoe/aoeblk.c~aoe-properly-initialise-the-request_queues-backing_dev_info
drivers/block/aoe/aoeblk.c
---
a/drivers/block/aoe/aoeblk.c~aoe-properly-initialise-the-request_queues-backing_dev_info
+++ a/drivers/block/aoe/aoeblk.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -210,25 +211,20 @@ aoeblk_gdalloc(void *vp)
if (gd == NULL) {
printk(KERN_ERR "aoe: cannot allocate disk structure for
%ld.%ld\n",
d->aoemajor, d->aoeminor);
- spin_lock_irqsave(>lock, flags);
- d->flags &= ~DEVFL_GDALLOC;
- spin_unlock_irqrestore(>lock, flags);
- return;
+ goto err;
}
d->bufpool = mempool_create_slab_pool(MIN_BUFS, buf_pool_cache);
if (d->bufpool == NULL) {
printk(KERN_ERR "aoe: cannot allocate bufpool for %ld.%ld\n",
d->aoemajor, d->aoeminor);
- put_disk(gd);
- spin_lock_irqsave(>lock, flags);
- d->flags &= ~DEVFL_GDALLOC;
- spin_unlock_irqrestore(>lock, flags);
- return;
+ goto err_disk;
}
- spin_lock_irqsave(>lock, flags);
blk_queue_make_request(>blkq, aoeblk_make_request);
+ if (bdi_init(>blkq.backing_dev_info))
+ goto err_mempool;
+ spin_lock_irqsave(>lock, flags);
gd->major = AOE_MAJOR;
gd->first_minor = d->sysminor * AOE_PARTITIONS;
gd->fops = _bdops;
@@ -246,6 +242,16 @@ aoeblk_gdalloc(void *vp)
add_disk(gd);
aoedisk_add_sysfs(d);
+ return;
+
+err_mempool:
+ mempool_destroy(d->bufpool);
+err_disk:
+ put_disk(gd);
+err:
+ spin_lock_irqsave(>lock, flags);
+ d->flags &= ~DEVFL_GDALLOC;
+ spin_unlock_irqrestore(>lock, flags);
}
void
_
--
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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Sat, 2007-12-08 at 02:07 -0800, Andrew Morton wrote:
> On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
> > > On Fri, 07 Dec 2007 23:09:43 +
> > > Zan Lynx <[EMAIL PROTECTED]> wrote:
> > [cut]
> > > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again,
> > > > > > but I
> > > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I
> > > > > > got
> > > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2
> > > > > > reader.
[cut]
> argh. OK. And Linus's current tree is OK, yes?
>
> In which case we should be OK for 2.6.24 and I guess we can hope like heck
> that the dud patch doesn't leak into mainline. Hopefully Alan will get
> some time to look into it before 2.6.25 opens.
Linus' tree is also broken.
I tried a Linus 2.6.24-rc4 and it acts the same way, with a very slow
transfer rate.
I also tried 2.6.24-rc4 with the older not-libata PATA drivers and it is
broken. dmesg had a line about the CF card detected as hda,
but /sys/block did not have hda and /dev/hda did not function.
I will try the patches you mentioned, but I think I may also have to
work backward through kernel versions until I find the last one where
the PCMCIA hd{a,b,c,d,e} drivers worked.
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] ps3: "mm/Kconfig" fix
On 12/08/2007 11:30 AM, Miguel Botón wrote: > sparsemem-make-sparsemem-vmemmap-selectable.patch introduces a little bug. > > SPARSEMEM_VMEMMAP can be enabled in an architecture that doesn't support it. > If the > architecture supports SPARSEMEM_VMEMMAP, SPARSEMEM_VMEMMAP_ENABLE is enabled, > so SPARSEMEM_VMEMMAP should depend on it. sparsemem-make-sparsemem-vmemmap-selectable.patch is still only in my ps3-linux-patches.git development repo. I'll just fold this into the original patch. Thanks. -Geoff -- 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.24-rc4-mm1 -- boot process hangs -- tty4 main process (2988) terminated with status 1
> > Dec 6 21:24:28 erratic-orbits init: tty3 main process (2991) > > terminated with status 1 > > Boggle. We broke the vt driver? > > config, please... I sent the .config. Is there nothing else to follow up on? I have tried rebuilding about seven kernels, tweaking the options each time. All the kernels have failed to boot. I am currently trying with a "defconfig" kernel. Perhaps I will have better luck with it. Thanks, Miles -- 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.24-rc4 hwmon it87 probe fails
On Sun, 9 Dec 2007 01:05:54 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: > > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and > > found that the it87 driver fails to probe and consequently, my > > sensors no longer work. This was fine with Linux 2.6.23.8 (the > > last kernel I was using) > > > > The necessary modules load, but: > > > > it87: Found IT8718F chip at 0x290, revision 2 > > it87: in3 is VCC (+5V) > > it87 it87.656: Failed to request region 0x290-0x297 > > it87: probe of it87.656 failed with error -16 > > > > Coretemp still works. > > > > It appears it has something to do with the ioport range being > > reserved for some reason: > > > > system 00:01: ioport range 0x290-0x29f has been reserved > > Thanks for your report. > > Please also provide: > - dmesg from 2.6.23.8 > - The output of "cat /proc/ioports" for both kernels Thanks Adrian, here is the information you have requested, for both kernels (I have 2.6.23.9 now though where it87 still works) Linux 2.6.23.9: http://www.mikeserv.com/temp/proc_ioports-2.6.23.9.txt http://www.mikeserv.com/temp/dmesg-2.6.23.9.txt http://www.mikeserv.com/temp/config-2.6.23.9.txt Linux 2.6.24-rc4: http://www.mikeserv.com/temp/proc_ioports-2.6.24-rc4.txt http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt http://www.mikeserv.com/temp/config-2.6.24-rc4.txt Mike Houston -- 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.24-rc4-git5: Reported regressions from 2.6.23
On Sat, Dec 08, 2007 at 11:30:53PM +0100, Rafael J. Wysocki wrote: > On Saturday, 8 of December 2007, Theodore Tso wrote: > > However, as far as I am concerned, Ingo's patch, first posted to LKML > > here: http://lkml.org/lkml/2007/11/16/66 should be listed as fixing > > the above regression. Rafael, could you please make a note of this in > > your regression list, > > Done, thanks. Great, thanks. I should add that technically this wasn't a regression since I had been seeing this since before 2.6.23. Also, it isn't a big deal, since aside from noise in the syslog, falling back to polling more doesn't make any functional or user-visible difference (although I guess it's less efficient). Regardless of whether it is a regression, it would be nice to get the patch applied and and this issue fixed for 2.6.25! - Ted -- 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: Please revert: PCI: fix IDE legacy mode resources
On Thu, Dec 06, 2007 at 05:24:22PM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2007-12-06 at 14:58 +0900, Yoichi Yuasa wrote: > > > What I don't understand is thus why you are calling resource_to_bus > > on 0x1f0 > > > which is -not- a resource value, but is already a BAR value... > > > > 0x1f0 is resource value on MIPS Cobalt. > > All RAW BAR values contain the offset(0x1000) on it. > > > > Do the BAR values on your target contain the offset? > > No, and I don't understand... raw BAR values don't contain such offset. > The physical address where the PIO is mapped might, but that's not what > we put in struct resource for IO resources and definitely not the BAR > value. > > The legacy IDE device will decode cycles at 0x1f0, not cycles at > 0x11f0. > > Take for example PowerPC. Imagine that I have a bus whose IO space is > mapped at 0xf000 in the processor physical address space (this is a > real example, my powermac does that for the x16 PCI-Express slot though > other slots use other offsets). > > Now, the kernel on ppc64 will map that virtually at some allocated > virtual address that we'll call we call bus_io_virt for this > explanation. In addition, inb() and outb() will apply an offset (which > can be different) that we call _IO_BASE to the port numbers. In general, > bus_io_virt of the first bus == _IO_BASE on ppc32 but that's not a > strict rule. > > Let's say for the sake of the example, that _IO_BASE is 0xd000 and > our bus has been mapped at 0xd001 (bus_io_virt). So 0xd001 maps > to 0xf000 via the MMU. > > When we scan the bus, we read the BAR content. So for example, a device > whose IOs have been assigned at 0x1000 will read that as a RAW bar value > and pci_scan_slot() (or whoever does the reading) will put 0x1000 in the > struct resource. In a similar vein, such a legacy controller would thus > be expected to have 0x1f0 in the resource. > > Later, when we fixup (in a head quirk on ppc32 and in pcibios_fixup_bus > on ppc64, though that's changing wit 2.6.25 to use the same mechanism), > we see an IO resource, and we fixup by adding to it basically > (bus_io_virt - _IO_BASE). > > That is, for our device that has a 0x1000 BAR value, we'll do: > > resource = 0x1000 + (0xd001 - 0xd000) = 0x11000 > > And for the legacy IDE: > > resource = 0x1f0 + (0xd001 - 0xd000) = 0x101f0 > > Now, if you do an inb or outb to one of these, the inb() and oub() > accessors will add _IO_BASE, which is 0xd000 in our example, so > you'll end up doing accesses to respectively: > > access = 0xd0011000 for the example device or > access = 0xd00101f0 for the IDE controller > > That translates via the MMU to > > phys = 0xf0001000 for the example device or > phys = 0xf1f0 for the IDE controller > > Which translates on to the bus into an IO cycle at the raw BAR > address (which is what is in the BAR content or hard-decoded in the case > of the legacy IDE): > > bus = 0x1000 for the example device > bus = 0x01f0 for the IDE controller > > which ... is what we started with. > > Now I don't understand how MIPS does things differently, but I can't see > how it can be legal to call pci_resource_to_bus() on 0x1f0 in > pci_setup_device(), because at this stage, we are putting raw BAR values > in the struct resource (that is PCI bus addresses) and 0x1f0 _is_ such a > value. > > Calling pci_resource_to_bus() would somewhat mean that 0x1f0 is not, and > instead is some kind of already fixed up resource value that we want > converted back into a BAR value, which is not the case. > > So I suspect your patch works by accident more than by design, or I am > missing something... So where do we stand with this? As I understand the Cobalt system controller it is not possible to address ioport addresses below 0x1000 at all on the PCI bus of the GT-64111. As such I think the best solution is a GT-64111-specific PCI fixup to clear out legacy resources. The IDE controller in the VIA VT82C586 could then be used only by its normal that is non-legacy address and commit fd6e732186ab522c812ab19c2c5e5befb8ec8115 could be reverted and PPC would be happy too? Ralf -- 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 2/6] random: use xor for mixing
On Sat, Dec 08, 2007 at 06:40:17PM -0600, Matt Mackall wrote: > I'm working on strengthening forward security for cases where the > internals are exposed to an attacker. There are any number of > situations where this can and does happen, and ensuring we don't > expose ourselves to backtracking is a worthwhile theoretical concern. See my other comments; I don't think we are currently vulnerable to backtracking. I tend to view backtracking as largely a theoretical concern, as most of the time, if the attacker has read access to kernel memory in order to compromise the internal state of /dev/random, the attacker very likely has *write* access to kernel memory, at which point you have much bigger problems to worry about, at least going forward. I suppose if you had *just* generated an 80-bit AES session key, right before the internal state was compromised, this might be interesting, but if the attacker can compromise arbitrary kernel memory, then attacker might as well just grab keying information from the userspace process --- such as perhaps the long-term private key of the user, or the data to be encrypted. So my personal take on it is that protecting against backtracking attacks is mainly useful in silencing academics who like to come up with, well, largely academic and theoretical scenario. If it doesn't take much effort, sure, let's try to protect against it (and I think we're OK already). But a much better use of our time would be spent creating userspace support so we can more efficiently pull entropy from TPM modules, or the noise from a sound/microphone input, etc., or other hardware sources of entropy. That would provide a much more practical improvement to the /dev/random subsystem than worry about what I feel are largely academic concerns. Regards, - Ted -- 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 6/6] random: improve variable naming, clear extract buffer
On Sat, Dec 08, 2007 at 05:21:00PM -0600, Matt Mackall wrote: > random: improve variable naming, clear extract buffer > > - split the SHA variables apart into hash and workspace > - rename data to extract > - wipe extract and workspace after hashing > > diff -r 924f9a441236 drivers/char/random.c > --- a/drivers/char/random.c Sat Dec 08 16:22:29 2007 -0600 > +++ b/drivers/char/random.c Sat Dec 08 16:32:31 2007 -0600 > @@ -461,7 +461,7 @@ static void __add_entropy_words(struct e > unsigned long flags; > /* rotate the add pointer more rapidly to span more of the >* pool on a given add */ > - const int step = 5; > + const int step = 13; > > /* Taps are constant, so we can load them without holding r->lock. */ > tap1 = r->poolinfo->tap1; This change has nothing to do with the patch comment. If you want to change the step size from 5 to 13, why not just change patch 5/6 to just use a step size of 13 from the beginning? Otherwise, yeah, this patch does make sense. Acked-by: "Theodore Ts'o" <[EMAIL PROTECTED]> - Ted -- 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 5/6] random: step more rapidly through the pool when adding and extracting
On Sat, Dec 08, 2007 at 05:20:39PM -0600, Matt Mackall wrote: > random: step more rapidly through the pool when adding and extracting > > Second, this patch spreads the mixing across the pool more rapidly by > using a larger step. For our secondary pools, we'll be sure to touch > both blocks with each mix, and for our primary pool, we'll change 5 of > 8 blocks. Yeah, that's a good idea. Acked-by: "Theodore Ts'o" <[EMAIL PROTECTED]> - Ted -- 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 4/6] random: make backtracking attacks harder
On Sat, Dec 08, 2007 at 05:20:38PM -0600, Matt Mackall wrote: > random: make backtracking attacks harder > > At each extraction, we change (poolbits / 16) + 32 bits in the pool, > or 96 bits in the case of the secondary pools. Thus, a brute-force > backtracking attack on the pool state is less difficult than breaking > the hash. In certain cases, this difficulty may be is reduced to 2^64 > iterations. OK, a backtracking attack assumes a fairly catastrophic case where the attacker has managed to compromise the internal pool state. In Linux, if an attacker has this much access, in most scenarios the attacker probably has the ability to gain write access to kernel memory as well, at which point you have far worse problems. The definition of a backtracking attack is when the attacker uses the current pool state to try to recover the last entropy extraction. As you point out, at each extraction, 96 bits are changed in the pool. But at each extraction, only 80 bits are extracted. If you are trying to find the value of the 80 bits that were extracted, and you know the current state of the pool, yes, you can take the 96 bits that were changed after the last extraction, and try all possible 2**96 combinations of the bits; but you probably won't rule anything out, since after you iterate over all of the 2**96 combinations, you'll probably be able to generate all of the 2**80 possible output bits. So you won't gain anything by trying to do a backtracking attack. So I don't think there's anything to worry about here. What you describe in your comments: > + * We mix the hash back into the pool to prevent backtracking > + * attacks (where the attacker knows the state of the pool > + * plus the current outputs, and attempts to find previous > + * ouputs), unless the hash function can be inverted. By > + * mixing at least a SHA1 worth of hash data back, we make > + * brute-forcing the feedback as hard as brute-forcing the > + * hash. >*/ sounds like not a backtracking attack, but an Iterative guessing attack, where "knowledge of internal state at some point and the intervening PRNG outputs, to learn internal state at a later point when the inputs collected during this span of time are guessable by the attacker." (Definition taken from: http://www.ee.oulu.fi/research/ouspg/frontier/sota/whitepaper-prng/) But note first of all, all this lets you do is unwind to an earlier state just before the known PRNG outputs. In order to use this to guess PRNG output, you still have to solve the above mentioned backtracking attack --- where you have 96 bits that changed, and 80 possible extraction bits. Secondly, the fact that we use catastrophic reseeding means that even if the state was compromised, at some point in time, every so often when we do a "catastrophic reseed", this acts as a firewall to limit the damage caused by a internal state exposure, both in the past and the future. - Ted -- 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/
rq_for_each_bio
I have tried to search through the mailing list and it is not entirely clear, but it looks like this has gone from the kernel: not least because my driver reports: drivers/sh/gdrom/gdrom.c:665: error: implicit declaration of function 'rq_for_each_bio' I am not arguing for a stable ABI/API, I get that one - but is there a canonical source of changes in the kernel (because unless you cross reference lkml and git repos the mailing list isn't) and if there is - how can we get it on the first page of google? :) (Actually, forget the theologocal discussion, tell me about rq_for_each_bio) -- 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: entropy gathering (was Re: Why does reading from /dev/urandom deplete entropy so much?)
On Sat, 2007-12-08 at 18:47 -0500, Theodore Tso wrote: > On Sat, Dec 08, 2007 at 09:42:39PM +0100, Willy Tarreau wrote: > > I remember having installed openssh on an AIX machines years ago, and > > being amazed by the number of sources it collected entropy from. Simple > > commands such as "ifconfig -a", "netstat -i" and "du -a", "ps -ef", "w" > > provided a lot of entropy. > > Well not as many bits of entropy as you might think. But every > little bit helps, especially if some of it is not available to > adversary. I was always especially fond of the "du" entropy source with Solaris installations of OpenSSH (the PRNG used commands like "du" too). It was always amusing that a single network outage at the University would prevent anyone from ssh'ing into the "UNIX" machines. So yeah, if we want to take a giant leap backwards, I suggest jumping at this. Lots of these are not actually random - you can guess the free space on a network drive in some certain cases, you know what processes are likely to be created on a LiveCD, and many dmesg outputs are very similar, especially when there aren't precie timestamps included. But I do think it's time some of this got addressed :-) Cheers, Jon. -- 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/4 -mm] kexec based hibernation -v7 : kexec jump
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: >> I'm not kexec hacker... but maybe this is in good enough state to be >> merged? It is useful on its own: kexec jump and back means we can dump >> system then continue running, for example... > > As far as I'm concerned, patches [1/4] and [2/4] can go. > > The other two are not in that shape yet (especially the [3/4] patch). Ok. Then I will see if I can review these in the next couple days and give some feedback. At a quick skim through the code it appears there is some more infrastructure then we need and things can still be simplified. Since this applies in particular to the user space interface I'm not comfortable with these patches going in just yet. The unused KEXEC_PRESERVE_ flags especially give me pause. Having something like that, that isn't currently wired up sounds like a bad place to start. Eric -- 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: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Kay Sievers wrote: On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote: Kay Sievers wrote: Is the udev daemon (still) running while it fails? Yes, and there's something else I forgot to mention that may be significant... For the bad case, in addition to udevd, "ps -ef" shows a "sh -e /lib/udev/net.agent" running with a PPID of 1. This process doesn't exit until I reboot. If this is normal under the circumstances, please disregard. Does SysRq-T show where it hangs? Ummm... No. I didn't have the CONFIG_MAGIC_SYSRQ flag set, so I set it, and recompiled the kernel. Guess what - now the system comes up normally without any problem. The block devices appear in /dev. To recap: without CONFIG_MAGIC_SYSRQ on the 2.6.24-rc3 kernel the missing block devices error in /dev occurs and the init scripts fall over on startup, and with CONFIG_MAGIC_SYSRQ the system comes up normally. To answer the earlier questions about distro, and udev version, my system is similar to Bob's, except that I am running Debian testing/lenny which comes with udev version 114 (dpkg reports udev version 0.114-2). I am running an EV67 variant CPU. I do not run an initramfs - I have the necessary drivers for the various discs compiled into the kernel and use the root kernel option to point to the required root partition. When running the broken kernel udev is running (according to 'ps') and executing /sbin/udevtrigger manually generates a number of errors of the form: scsi_id[]: scsi_id: unable to access '/block' The missing /dev/* entries do not appear. Cheerz Michael. -- 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: Bug: get EXT3-fs error Allocating block in system zone
On Sat, 8 Dec 2007, Marco Gatti wrote: > > Today, I tested with different amounts of RAM: > > 2 GB: everything works fine > 4 GB: same issue as described before with allocating block in system zone > > So what to do, in order to use more than 2 Gigs of RAM? Was there a dmesg out there somewhere? With 4G of RAM, you probably have some of it above the 4GB mark (because of RAM remapping etc, and the PCI decode hole in the low 4GB). It does sound like this is a DMA problem, and your controller cannot correctly DMA to the upper 4GB. So what controller/driver, what's the dmesg, and let's see if we can fix it by adding a DMA mask to it to limit it to the low 32 bits. Linus -- 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 2/6] random: use xor for mixing
On Sat, Dec 08, 2007 at 07:01:04PM -0500, Theodore Tso wrote: > On Sat, Dec 08, 2007 at 05:20:16PM -0600, Matt Mackall wrote: > > random: use xor for mixing > > > > With direct assignment, we can determine the twist table element used > > for mixing (the high 3 bits of the table are unique) and reverse a > > single step of mixing. Instead, use xor, which should also help > > preserve entropy in a given pool slot. > > > > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> > > > > diff -r bc336762cfdb drivers/char/random.c > > --- a/drivers/char/random.c Wed Dec 05 17:20:02 2007 -0600 > > +++ b/drivers/char/random.c Sat Dec 08 13:27:34 2007 -0600 > > @@ -496,7 +496,7 @@ static void __add_entropy_words(struct e > > w ^= r->pool[(i + tap4) & wordmask]; > > w ^= r->pool[(i + tap5) & wordmask]; > > w ^= r->pool[i]; > > - r->pool[i] = (w >> 3) ^ twist_table[w & 7]; > > + r->pool[i] ^= (w >> 3) ^ twist_table[w & 7]; > > } > > In the original design of add_entropy_words(), in order to provably > not lose any entropy, you want add_entropy_words() to be reversible if > you mix in all zero's. Ahh, yes, that's true. I'd somehow missed that we effectively had a tap at 0, so I thought this was actually improving the situation. I'll replace this with a comment explaining the situation. > The internals of the pool are never exposed, so an attacker should > never gain direct access to the entropy pool; hence worry about > whether someone can "reverse" the mixing isn't particuarly a worry; > indeed, in order to make sure we preserve entropy, the whole *point* > of the mixing algorithm is that it is reversible. I'm working on strengthening forward security for cases where the internals are exposed to an attacker. There are any number of situations where this can and does happen, and ensuring we don't expose ourselves to backtracking is a worthwhile theoretical concern. --- random: document revisibility of mixing function. Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> diff -r bc336762cfdb drivers/char/random.c --- a/drivers/char/random.c Wed Dec 05 17:20:02 2007 -0600 +++ b/drivers/char/random.c Sat Dec 08 18:38:15 2007 -0600 @@ -447,6 +447,12 @@ static struct entropy_store nonblocking_ * degree, and then twisted. We twist by three bits at a time because * it's cheap to do so and helps slightly in the expected case where * the entropy is concentrated in the low-order bits. + * + * This function is intentionally reversible, meaning that if we mix + * in known values, we can run the algorithm backwards and recover the + * earlier state. Because we can recover the original state, we are + * provably not destroying any existing entropy content in the pool + * when we mix. */ static void __add_entropy_words(struct entropy_store *r, const __u32 *in, int nwords, __u32 out[16]) -- Mathematics is the supreme nostalgia of our time. -- 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 3/6] random: do extraction before mixing
On Sat, Dec 08, 2007 at 05:20:17PM -0600, Matt Mackall wrote:
> random: do extraction before mixing
>
> If an attacker manages to capture the current pool state, she can
> determine the last 10 bytes extracted from the pool.
That's not true; we aren't just extracting data in the
__add_entropy_words() call. In fact, above that, the bulk of the
extraction comes form when we hash the entire pool, feeding back a
portion of the hash into the pool here:
for (i = 0; i < r->poolinfo->poolwords; i += 16) {
/* hash blocks of 16 words = 512 bits */
sha_transform(buf, (__u8 *)(r->pool + i), buf + 5);
/* feed back portion of the resulting hash */
add_entropy_words(r, [i % 5], 1);
}
So the buf[0..5] contains a hash of the entire pool, and every 16
words, we're already mixing 32 bits into the pool. So even if the
attacker captures the current pool state, she's not going to be able
to undo the intermediate SHA values that had been mixed into the pool.
> By mixing after
> the extraction, this is made substantially harder.
Not that much harder; as I mentioned as comments in my last patch, we
are doing a linear polynomial mixing for speed purposes, so relying on
the mixing to obscure the extraction isn't going to help much.
But that's OK, we don't need to depend on that. Note the amount of
feedback that we do in the above loop.
- Ted
--
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 2/3] ptrace_stop: remove the wrong ->group_stop_count bookkeeping
Oleg Nesterov <[EMAIL PROTECTED]> writes: > ptrace_stop() decrements ->group_stop_count to "participate" in group stop. > This looks very wrong to me, the task can in fact decrement this counter > twice. > If the tracee returns to the user-space before other threads complete the > group > stop, it will notice TIF_SIGPENDING and do it again. This is one of those interesting weird cases. The ptrace interface remains per task. So need to handle a simultaneous thread group stop and a per task stop. > > Another problem is that we don't set SIGNAL_STOP_STOPPED if the counter > becomes > zero. > > I must admit, I don't undestand the reason why this code was added, it is very > old. I haven't dug in enough yet to understand better, but it is my hunch we need to do something when we have both kinds of stop happening simultaneously. Eric -- 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: Major regression on hackbench with SLUB
Ingo, Due to email problems, I never got your reply on this thread. But I saw your reply when reading this thread on lkml.org (nor did I receive Linus's first reply). Anyway, I booted 2.6.24-rc4-mm1 with the same config, and accepted the defaults to the new config options as the git version I checked. And it gave me an average of 12.5 second runs. Here's the oprofile for it: http://people.redhat.com/srostedt/slub/results/slub-mm.op -- Steve -- 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: Allow (O=...) from file
On Sat, 8 Dec 2007 21:14:09 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > Jay - can I ask you to try out following patch. Hello Sam, Yes, your patch works for me. Thank you very much. > diff --git a/Makefile b/Makefile > index a5252f4..7fb1a2c 100644 > --- a/Makefile > +++ b/Makefile > @@ -118,9 +118,6 @@ saved-output := $(KBUILD_OUTPUT) > KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd) > $(if $(KBUILD_OUTPUT),, \ > $(error output directory "$(saved-output)" does not exist)) > -# Check that OUTPUT directory is not the same as where we have > kernel src -$(if $(filter-out $(KBUILD_OUTPUT),$(shell /bin/pwd)),, \ > - $(error Output directory (O=...) specifies kernel src dir)) > > PHONY += $(MAKECMDGOALS) sub-make > > diff --git a/scripts/mkmakefile b/scripts/mkmakefile > index ee39fac..9ad1bd7 100644 > --- a/scripts/mkmakefile > +++ b/scripts/mkmakefile > @@ -11,6 +11,12 @@ > > > test ! -r $2/Makefile -o -O $2/Makefile || exit 0 > +# Only overwrite automatically generated Makefiles > +# (so we do not overwrite kernel Makefile) > +if ! grep -q Automatically $2/Makefile > +then > + exit 0 > +fi > echo " GEN $2/Makefile" > > cat << EOF > $2/Makefile > -- -- 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.24-rc3-git4 NFS crossmnt regression
On Saturday 08 December 2007 01:43:28 Rafael J. Wysocki wrote: > On Saturday, 8 of December 2007, Andrew Morton wrote: > > On Fri, 07 Dec 2007 17:51:58 -0500 > > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > > > > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote: > > > > On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote: > > > > ... > > > > > Confirmed working in rc4-git5. I'll deploy this kernel in a few more > > > > > spots and check for other regressions. > > > > > > > > Hmm, I installed a new kernel built from the same sources on the NFS > > > > server. And now I don't see anything at all in the crossmnt dirs. > > > > > > > > ls /dirA/dirB/dirC --> zero output (empty dir) > > > > > > > > Are there any other pending fixes? Hi, Due to the fact that I was bitten by this bug (I thought it is a feature), and a bit of lack of understanding of NFS4 I want to ask few questions about NFS: 1) I want to export whole file-system with submounts to a range of clients. As 'exports' manual says I can't do so, is that true? Can you tell me how properly to use crossmnt and nohide? Where should I put those options in root file-system export or in submount export? 2) NFS4 - I can't get it working: *I have a LFS system, and this is what I did (NFS3 works fine, but crossmnt, and nohide seems not to work, probably due to above bug) I also have seen errors about stale handles *Kernel - 2.6.24-rc3 with NFS3/4 client/server enabled on both host and guest. (both client and server running this kernel) *rpc.idmapd running on both client and server + all standard NFS3 tools *NFS tools 1.1.1 with nfs4 support compiled + without GSS (on server) * /etc/exports with fsid=0: (on server) /tmp *(fsid=0,insecure,rw,async,anonuid=100,anongid=1000) * mounting with -tnfs4 server:/ /mnt/tmp Still doesn't work, using wireshark shows that NFSV4 COMPOUND call with Opcode: PUTROOTFH (24) Opcode: GETFH (10) Opcode: GETATTR (9) Fails with Reject State: AUTH_ERROR (1) Auth State: bad credential (seal broken) (1) Any ideas? (I decided to switch to NFS4 only due to the lack of ability to see underlying mounts) The system I am connecting to is a very old P1 system I use as a terminal (X and ssh) When I need to install something there I mount whole / of in on my main Core2 system chroot there, and compile/install. Best regrads, Maxim Levitsky -- 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.24-rc4 hwmon it87 probe fails
On Tue, Dec 04, 2007 at 09:51:54PM -0500, Mike Houston wrote: > I finally got around to testing Linux 2.6.24 (2.6.24-rc4) and found > that the it87 driver fails to probe and consequently, my sensors no > longer work. This was fine with Linux 2.6.23.8 (the last kernel I was > using) > > The necessary modules load, but: > > it87: Found IT8718F chip at 0x290, revision 2 > it87: in3 is VCC (+5V) > it87 it87.656: Failed to request region 0x290-0x297 > it87: probe of it87.656 failed with error -16 > > Coretemp still works. > > It appears it has something to do with the ioport range being > reserved for some reason: > > system 00:01: ioport range 0x290-0x29f has been reserved > > At least I don't see that happening on previous kernels. > > In any case, the changes to it87.c itself don't appear to have caused > this. (CC'd hwmon maintainer anyways, my apologies if that was > inappropriate) > > dmesg: > http://www.mikeserv.com/temp/dmesg-2.6.24-rc4.txt > > config: > http://www.mikeserv.com/temp/config-2.6.24-rc4.txt Thanks for your report. Please also provide: - dmesg from 2.6.23.8 - The output of "cat /proc/ioports" for both kernels > Thanks for any help or suggestions, > > Mike Houston cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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.23.9 64-bit IRQ sharing without irqbalance with p35 vs i965?
On Sat, 8 Dec 2007 18:44:39 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]> wrote: > Can some please explain with almost identical kernel .config's I see > this on a p965 Intel board: your bios programmed the machines differently... the p965 has the higher performing settup, but still it's recommended to run the http://www.irqbalance.org program to spread interrupts around -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/4 -mm] kexec based hibernation -v7 : kexec jump
On Sunday, 9 of December 2007, Pavel Machek wrote: > Hi! > > > This patch implements the functionality of jumping between the kexeced > > kernel and the original kernel. > > > > To support jumping between two kernels, before jumping to (executing) > > the new kernel and jumping back to the original kernel, the devices > > are put into quiescent state, and the state of devices and CPU is > > saved. After jumping back from kexeced kernel and jumping to the new > > kernel, the state of devices and CPU are restored accordingly. The > > devices/CPU state save/restore code of software suspend is called to > > implement corresponding function. > > > > To support jumping without reserving memory. One shadow backup page > > (source page) is allocated for each page used by new (kexeced) kernel > > (destination page). When do kexec_load, the image of new kernel is > > loaded into source pages, and before executing, the destination pages > > and the source pages are swapped, so the contents of destination pages > > are backupped. Before jumping to the new (kexeced) kernel and after > > jumping back to the original kernel, the destination pages and the > > source pages are swapped too. > > > > A jump back protocol for kexec is defined and documented. It is an > > extension to ordinary function calling protocol. So, the facility > > provided by this patch can be used to call ordinary C function in real > > mode. > > > > A set of flags for sys_kexec_load are added to control which state are > > saved/restored before/after real mode code executing. For example, you > > can specify the device state and FPU state are saved/restored > > before/after real mode code executing. > > > > The states (exclude CPU state) save/restore code can be overridden > > based on the "command" parameter of kexec jump. Because more states > > need to be saved/restored by hibernating/resuming. > > > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> > > I'm not kexec hacker... but maybe this is in good enough state to be > merged? It is useful on its own: kexec jump and back means we can dump > system then continue running, for example... As far as I'm concerned, patches [1/4] and [2/4] can go. The other two are not in that shape yet (especially the [3/4] patch). Greetings, Rafael -- 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 2/6] random: use xor for mixing
On Sat, Dec 08, 2007 at 05:20:16PM -0600, Matt Mackall wrote: > random: use xor for mixing > > With direct assignment, we can determine the twist table element used > for mixing (the high 3 bits of the table are unique) and reverse a > single step of mixing. Instead, use xor, which should also help > preserve entropy in a given pool slot. > > Signed-off-by: Matt Mackall <[EMAIL PROTECTED]> > > diff -r bc336762cfdb drivers/char/random.c > --- a/drivers/char/random.c Wed Dec 05 17:20:02 2007 -0600 > +++ b/drivers/char/random.c Sat Dec 08 13:27:34 2007 -0600 > @@ -496,7 +496,7 @@ static void __add_entropy_words(struct e > w ^= r->pool[(i + tap4) & wordmask]; > w ^= r->pool[(i + tap5) & wordmask]; > w ^= r->pool[i]; > - r->pool[i] = (w >> 3) ^ twist_table[w & 7]; > + r->pool[i] ^= (w >> 3) ^ twist_table[w & 7]; > } In the original design of add_entropy_words(), in order to provably not lose any entropy, you want add_entropy_words() to be reversible if you mix in all zero's. So the fact that you can determine the twist table element used from looking at the high bits was deliberate. The mixing done in add_entropy_words() is *not* intended to be cryptographic, but merely to smear the bits around as they are added and then to permute the pool so that when you use SHA in the output stage, enough bits are changing that even if there are weaknesses discovered in the crypto hash algorithm, it won't help the attacker. The internals of the pool are never exposed, so an attacker should never gain direct access to the entropy pool; hence worry about whether someone can "reverse" the mixing isn't particuarly a worry; indeed, in order to make sure we preserve entropy, the whole *point* of the mixing algorithm is that it is reversible. (note: credit for this design should go to Colin Plumb, who worked with me on this aspect of the design. Colin was responsible for the original random number generator in PGP) - Ted -- 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/4 -mm] kexec based hibernation -v7 : kexec jump
Hi! > This patch implements the functionality of jumping between the kexeced > kernel and the original kernel. > > To support jumping between two kernels, before jumping to (executing) > the new kernel and jumping back to the original kernel, the devices > are put into quiescent state, and the state of devices and CPU is > saved. After jumping back from kexeced kernel and jumping to the new > kernel, the state of devices and CPU are restored accordingly. The > devices/CPU state save/restore code of software suspend is called to > implement corresponding function. > > To support jumping without reserving memory. One shadow backup page > (source page) is allocated for each page used by new (kexeced) kernel > (destination page). When do kexec_load, the image of new kernel is > loaded into source pages, and before executing, the destination pages > and the source pages are swapped, so the contents of destination pages > are backupped. Before jumping to the new (kexeced) kernel and after > jumping back to the original kernel, the destination pages and the > source pages are swapped too. > > A jump back protocol for kexec is defined and documented. It is an > extension to ordinary function calling protocol. So, the facility > provided by this patch can be used to call ordinary C function in real > mode. > > A set of flags for sys_kexec_load are added to control which state are > saved/restored before/after real mode code executing. For example, you > can specify the device state and FPU state are saved/restored > before/after real mode code executing. > > The states (exclude CPU state) save/restore code can be overridden > based on the "command" parameter of kexec jump. Because more states > need to be saved/restored by hibernating/resuming. > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> I'm not kexec hacker... but maybe this is in good enough state to be merged? It is useful on its own: kexec jump and back means we can dump system then continue running, for example... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/3] will_become_orphaned_pgrp: we have threads
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> p->exit_state != 0 doesn't mean this process is dead, it may have sub-threads.
>
> However, the new "p->exit_state && thread_group_empty(p)" check is not correct
> either, this is just the temporary hack. Perhaps we can just remove this
> check,
> but I don't understand orphaned process groups magic. At all. However, I think
> exit_notify() is obviously and completely wrong wrt this helper.
The problem that orphaned processes groups address is what happens if
an entire process group is stopped, and there is not a process that
can wake them up.
The rule for an unprivileged process sending a signal to a process
group is that it must be in the same session as the process group.
The rule for sending a signal to a process group is that the signal sender
must be in the same session.
So we are testing for a process group that does not have a living
member with a parent outside of the process that can send the process
group a signal.
The test for init seems bogus. /sbin/init rarely if ever starts
processes in it's own session which is likely why this has not caused
problems. If we keep the test for init we need to make the test
is_container_init rather the is global_init.
As for exit_notify I agree. We need a thread_group_exit_notify.
That is responsible for performing work when we know the entire
thread group has exited. Sending the exit_signal and performing
the through group orphaned check look like two of those tasks
that need to be performed only at thread group exit.
Oleg what do you see wrong with checking p->exit_state &&
thread_group_empty(p)? Since non-leader threads all self reap
that seems to be a valid test for an dead thread group.
Eric
> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
>
> --- PT/kernel/exit.c~4_orphaned_pgrp 2007-12-06 18:06:09.0 +0300
> +++ PT/kernel/exit.c 2007-12-07 20:25:40.0 +0300
> @@ -219,9 +219,9 @@ static int will_become_orphaned_pgrp(str
> int ret = 1;
>
> do_each_pid_task(pgrp, PIDTYPE_PGID, p) {
> - if (p == ignored_task
> - || p->exit_state
> - || is_global_init(p->real_parent))
> + if ((p == ignored_task) ||
> + (p->exit_state && thread_group_empty(p)) ||
> + is_global_init(p->real_parent))
> continue;
> if (task_pgrp(p->real_parent) != pgrp &&
> task_session(p->real_parent) == task_session(p)) {
--
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: entropy gathering (was Re: Why does reading from /dev/urandom deplete entropy so much?)
On Sat, Dec 08, 2007 at 09:42:39PM +0100, Willy Tarreau wrote: > I remember having installed openssh on an AIX machines years ago, and > being amazed by the number of sources it collected entropy from. Simple > commands such as "ifconfig -a", "netstat -i" and "du -a", "ps -ef", "w" > provided a lot of entropy. Well not as many bits of entropy as you might think. But every little bit helps, especially if some of it is not available to adversary. - Ted -- 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: Why does reading from /dev/urandom deplete entropy so much?
On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote: > > As long as /dev/random is readable for all users there's no reason to > > use /dev/urandom for a local DoS... > > Draining entropy in /dev/urandom means that insecure and possibly not random > data will be used and well thats a security bug if not a DoS bug. Actually in modern 2.6 kernels there are two separate output entropy pools for /dev/random and /dev/urandom. So assuming that the adversary doesn't know the contents of the current state of the entropy pool (i.e., the RNG is well seeded with entropy), you can read all you want from /dev/urandom and that won't give an adversary successful information to attack /dev/random. - Ted -- 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/
2.6.23.9 64-bit IRQ sharing without irqbalance with p35 vs i965?
Can some please explain with almost identical kernel .config's I see this on a p965 Intel board: CPU0 CPU1 CPU2 CPU3 0: 2501669875 0 0 0 IO-APIC-edge timer 1: 8 0 0 0 IO-APIC-edge i8042 7: 0 0 0 0 IO-APIC-edge parport0 8: 1 0 0 0 IO-APIC-edge rtc 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 21187797 0 0 0 IO-APIC-edge i8042 16: 29096123 0 0 0 IO-APIC-fasteoi sata_sil24, uhci_hcd:usb3 17:122 0 0 0 IO-APIC-fasteoi libata 18: 27177188 0 0 0 IO-APIC-fasteoi sata_sil24, ehci_hcd:usb1, uhci_hcd:usb7 19: 29230654 0 0 0 IO-APIC-fasteoi sata_sil24, ohci1394, uhci_hcd:usb6 21: 41626956 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4, eth1 22:203 0 0 0 IO-APIC-fasteoi HDA Intel 23:108 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5 377: 590862399 0 0 0 PCI-MSI-edge eth0 378: 89967666 0 0 0 PCI-MSI-edge ahci NMI: 0 0 0 0 LOC: 2501568889 2501566748 2501569508 2501566435 ERR: 0 And this on a Gigabyte p35 chipset: CPU0 CPU1 CPU2 CPU3 0:4798363480624248071034801203 IO-APIC-edge timer 1: 1 2 3 2 IO-APIC-edge i8042 6: 3 0 0 0 IO-APIC-edge floppy 8: 0 0 0 1 IO-APIC-edge rtc 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 22 32 26 33 IO-APIC-edge i8042 16: 0 0 0 0 IO-APIC-fasteoi ahci, uhci_hcd:usb3 17: 16994 17065 16955 16952 IO-APIC-fasteoi libata, eth0 18: 0 1 1 1 IO-APIC-fasteoi ohci1394, ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb7 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 38 39 40 38 IO-APIC-fasteoi HDA Intel 23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 380:6838702682341168227046836873 PCI-MSI-edge ahci NMI: 0 0 0 0 LOC: 18993695 18993662 18891135 18891030 ERR: 0 Both are running Debian Lenny (testing) with (almost the same exact kernel configuration). Why is this? Justin. -- 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] scheduler: fix x86 regression in native_sched_clock
On Dec 8, 2007 9:52 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > the scariest bit isnt even the scaling i think - that is a fairly > straightforward and clean PER_CPU-ization of the global scaling factor, > and its hookup with cpufreq events. (and the credit for that goes to > Guillaume Chazarain) To be fair, the cpufreq hook were already there, I just did a buggy percpu conversion and added an offset that you removed ;-) -- Guillaume -- 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: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]
On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> i'm wondering why it had no effect now
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e0d3a4f..a46c252 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -47,15 +47,21 @@ void __init cpu_hotplug_init(void)
}
#ifdef CONFIG_HOTPLUG_CPU
-
+#include
void get_online_cpus(void)
{
+ outb(0x20, 0x80);
might_sleep();
+ outb(0x21, 0x80);
if (cpu_hotplug.active_writer == current)
return;
+ outb(0x22, 0x80);
mutex_lock(_hotplug.lock);
+ outb(0x23, 0x80);
cpu_hotplug.refcount++;
+ outb(0x24, 0x80);
mutex_unlock(_hotplug.lock);
+ outb(0x25, 0x80);
}
EXPORT_SYMBOL_GPL(get_online_cpus);
produces 0x22 on the LCD (called from watchdog kthread).
Going to catch some sleep,
--js
--
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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE and CONFIG_NO_HZ. I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last - that way we can at least tell what is required to be hit with this problem. Parag -- 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: [Bugme-new] [Bug 9482] New: kernel GPF in 2.6.24 (g09f345da)
I can confirm that 2.6.24rc4 with the (second) patch works fine. -- Jon -- 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: lockdep problem conversion semaphore->mutex (dev->sem)
Peter Zijlstra wrote, On 12/08/2007 09:50 PM: > On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > >> Which problems? I did not see any special things, it looked rather >> straight forward. What have I overlooked? > > On suspend it locks the whole device tree, this means it has 'unbounded' > nesting and holds an 'unbounded' number of locks. Neither things are > easy to annotate (remember that mutex_lock_nested can handle up to 8 > nestings and current->held_locks has a max of 30). > > In fact, converting this will be the hardest part, it would require > reworking the locking and introduction of a hard limit on the device > tree depth - this might upset some people, but I suspect that 16 or 24 > should be deep enough for pretty much anything. Of course, if people > prove me wrong, I'll have to reconsider. The up-side of the locking > scheme I'm thinking of will be that locking the whole tree will only > take 'depth' number of opterations vs the total number of tree elements. Of course, I don't know the problem enough, and would be glad if somebody give me a hint, but I wonder why so deep nesting with lockdep's modification is necessary here? Does buses have parent buses and so on x8? Why isn't here considered creating of different lockdep classes according to types of buses and devices "the usual way"? This way seems to be quite easy in later debugging. Regards, Jarek P. -- 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] swap image signature check upon resume
On Saturday, 8 of December 2007, Borislav Petkov wrote: > On Fri, Dec 07, 2007 at 09:19:09PM +0100, Rafael J. Wysocki wrote: > > ... > > > > > Well, there's a patchset in the current mainline that allows you to use > > > > arbitrary (sufficiently new) kernel to load the image and then restore > > > > the > > > > image kernel. So, you can hibernate 2.6.24-rc3 and use 2.6.24-rc2 to > > > > restore > > > > it, for example. > > > > > > > > I'm going to do that for i386 too. > > > right, this is d307c4a8e826c44f9633bd3f7e60d0491e7d885a (Hibernation: > > > Arbitrary > > > boot kernel support - generic code), i should've seen that. What's the > > > status of > > > those bits, from a quick scan it seems they need some rewiring (Kconfig, > > > e.g. > > > CONFIG_ARCH_HIBERNATION_HEADER etc..) and arch-specific save and restore > > > functions? > > > > No, this code is fully functional. :-) > > > > The arch save and restore functions are in arch/x86/kernel/suspend_64.c . > > > > As I said, i386 is not yet supported. > > nice, holler if you need a tester when you have some prototypes ready. By the > way, > what do you do when the suspend image header mismatches and it is unsafe to > continue booting? If the image header doesn't match, we don't load it and return an error code, which usually results in the boot kernel continuing to boot. > Also, there's a freakishly long comment in suspend_64.c, might wanna shorten > it: Ah, OK. I'll take your patch for 2.6.25, thanks. > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> > > diff --git a/arch/x86/kernel/suspend_64.c b/arch/x86/kernel/suspend_64.c > index db284ef..0a23e5f 100644 > --- a/arch/x86/kernel/suspend_64.c > +++ b/arch/x86/kernel/suspend_64.c > @@ -118,7 +118,12 @@ void fix_processor_context(void) > int cpu = smp_processor_id(); > struct tss_struct *t = _cpu(init_tss, cpu); > > - set_tss_desc(cpu,t);/* This just modifies memory; should not be > necessary. But... This is necessary, because 386 hardware has concept of busy > TSS or some similar stupidity. */ > + /* > + * This just modifies memory; should not be necessary. But... This > + * is necessary, because 386 hardware has concept of busy TSS or some > + * similar stupidity. > + */ > + set_tss_desc(cpu,t); > > cpu_gdt(cpu)[GDT_ENTRY_TSS].type = 9; > > @@ -138,7 +143,6 @@ void fix_processor_context(void) > loaddebug(>thread, 6); > loaddebug(>thread, 7); > } > - > } > > #ifdef CONFIG_HIBERNATION > -- 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: Major regression on hackbench with SLUB
Hi Linus, > On Fri, 7 Dec 2007, Linus Torvalds wrote: > > > > Can you do one run with oprofile, and see exactly where the cost is? It > > should hopefully be pretty darn obvious, considering your timing. The results are here: http://people.redhat.com/srostedt/slub/results/slab.op http://people.redhat.com/srostedt/slub/results/slub.op > > Anyway, it's unclear whether the reason it goes into the slow-path because > the freelist is just always empty, or whether it hits the > > ... || !node_match(c, node) I did two things. First I tried making node_match always return true, the second was just commenting out the above check. They both had pretty much the exact same results. It slowed down by double! Instead of taking 15 seconds to complete, both took 30 seconds to complete. Here's the oprofiles of those runs. node_match return 1: http://people.redhat.com/srostedt/slub/results/slub-nonode.op comment out node_match check: http://people.redhat.com/srostedt/slub/results/slub-nochecknode.op > > [ The whole node match thing is likely totally bogus. I suspect we pay > *more* in trying to match nodes than we'd ever likely pay in just > returning the wrong node for an allocation, but that's neither here nor > there ] I don't think it's bogus by the result that removing it slowes it down by half. I'm wondering if there's not some other cache thrashing happening somewhere else in the slub code. I'll start adding some stats in the code to see where the congestion might lie. I'll look into this on Monday. Seems that both SLAB and SLUB run kernel compiles the same. Here's the results of my compile test. (make -j256 and chrt -f 10 make -j256) http://people.redhat.com/srostedt/slub/ -- Steve -- 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: scsi_wait_scan Kconfig option
On Sat, Dec 08, 2007 at 10:21:11PM +0100, Stefan Richter wrote: > Besides, in order for scsi_wait_scan to work, drivers need to support it > explicitly, don't they? If so, simply kill the "default m" from config > SCSI_WAIT_SCAN and let any driver which is integrated with it select it. No. All drivers which call scsi_scan_host() support it. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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.24-rc4-git5: Reported regressions from 2.6.23
On Saturday, 8 of December 2007, Richard Purdie wrote: > On Sat, 2007-12-08 at 03:40 +0100, Rafael J. Wysocki wrote: > > Subject : leds: ledtrig-timer calls sleeping function from > > invalid context > > Submitter : Márton Németh <[EMAIL PROTECTED]> > > References : http://bugzilla.kernel.org/show_bug.cgi?id=9264 > > Handled-By : Richard Purdie <[EMAIL PROTECTED]> > > Patch : > > http://bugzilla.kernel.org/attachment.cgi?id=13493=view > > The fix is now in mainline: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dc47206e552c0850ad11f7e9a1fca0a3c92f5d65 Yes, already dropped. Thanks, Rafael -- 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.24-rc4-git5: Reported regressions from 2.6.23
On Saturday, 8 of December 2007, Theodore Tso wrote: > On Sat, Dec 08, 2007 at 01:42:41AM -0800, Andrew Morton wrote: > > > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always > > > work on Lenovo X60s > > > Submitter : Roland Dreier <[EMAIL PROTECTED]> > > > References: http://lkml.org/lkml/2007/11/8/255 > > > http://bugzilla.kernel.org/show_bug.cgi?id=9332 > > > Handled-By: > > > Patch : > > > > Takashi had a patch and that has been merged. AFAIK this regression > > has been fixed and we're left with a new but harmless warning. > > > > However Roland reported other problems and it appears that the trail went > > cold (http://lkml.org/lkml/2007/11/14/251) > > > > Ted was hitting some of the same problems but that trail appears to also > > have gone cold (http://lkml.org/lkml/2007/11/23/17). > > Actually, not gone cold, but I stopped posting about it because it's > been solved and I thought agreement had been reached that it should be > pushed to mainline before 2.6.25. > > I am very happily running with Ingo's "snd hda suspend latency: > shorten codec read" patch, which was originally intended to speed up > resuming from hibernation, but which as I discovered, also has the > nice side effect of eliminating the reported error. > > On 11/23, Takashi replied to my note (http://lkml.org/lkml/2007/11/23/17) > and suggested that Jaroslav push this patch to Linus immediately > instead of waiting for 2.6.25, since it appearly solves two problems > with one stone. However, I just checked, as of Linus's public, and > Ingo's patch is *not* in mainline. > > However, as far as I am concerned, Ingo's patch, first posted to LKML > here: http://lkml.org/lkml/2007/11/16/66 should be listed as fixing > the above regression. Rafael, could you please make a note of this in > your regression list, Done, thanks. > and could we please get this patch pushed into mainline? -- 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: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 00:03:45 tarihinde Adrian Bunk şunları yazmıştı: > On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote: > >... > > Sounds like a local DoS attack point to me... > > As long as /dev/random is readable for all users there's no reason to > use /dev/urandom for a local DoS... Draining entropy in /dev/urandom means that insecure and possibly not random data will be used and well thats a security bug if not a DoS bug. And yes this is by design, sigh. -- Never learn by your mistakes, if you do you may never dare to try again. -- 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: Why does reading from /dev/urandom deplete entropy so much?
On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote: >... > Sounds like a local DoS attack point to me... As long as /dev/random is readable for all users there's no reason to use /dev/urandom for a local DoS... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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.24-rc4-git5: Reported regressions from 2.6.23
On Saturday, 8 of December 2007, Andrew Morton wrote: > On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > This message contains a list of some regressions from 2.6.23 which have been > > reported since 2.6.24-rc1 was released and for which there are no fixes in > > the > > mainline that 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.23, please let me > > know > > either and I'll add them to the list. > > Twenty nine, huh? > > It would be useful if these records were sorted in date-of-reportage order > and had a date stamp so we could see how long they've been hanging about. They are sorted by the bugzilla number which reflects the date-of-reportage order pretty well. For a techincal reason, it's easier to me if they're sorted like this. Adding date stamps should be easy, tough, I'll try to add them to the next report. > Something to think about for the post-2.6.24 regression if you'll be handling > those? Yes, I'm going to handle the post-2.6.24 regressions too (in the hope there will be less of them ;-)). > > Subject : leds: ledtrig-timer calls sleeping function from > > invalid context > > Submitter : Márton Németh <[EMAIL PROTECTED]> > > References : http://bugzilla.kernel.org/show_bug.cgi?id=9264 > > Handled-By : Richard Purdie <[EMAIL PROTECTED]> > > Patch : > > http://bugzilla.kernel.org/attachment.cgi?id=13493=view > > That patch has been merged (dc47206e552c0850ad11f7e9a1fca0a3c92f5d65) and > assuming Márton has tested the latest git snapshot > (ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots) successfully we can > cross it off? Yes, will drop. Thanks, Rafael -- 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: Correct types for mod_devicetable.h (was: Re: m68k build failure)
On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote: > On Sunday 02 December 2007 22:22:31 Geert Uytterhoeven wrote: > > On Sat, 1 Dec 2007, Pierre Ossman wrote: > > > Yeah, that could work. Have a header with stuff like this: > > > > > > typedef u16 __attribute__((aligned(2))) aligned_u16; > > > typedef u32 __attribute__((aligned(4))) aligned_u32; > > > > I gave it a try: > > This seems to turn a molehill into a mountain. > > We can change that mod_devicetable.h at any time; it's not supposed to be a > userspace API (the kernel build system doesn't count). module-init-tools is userspace and not shipped as part of the kernel build system... > So, just insert two bits of padding in sdio_device_id and insert a comment > saying "/* Explicit padding: works even if we're cross-compiling */". We had one such problem in 2.6.23 and now we had a similar one in 2.6.24. Getting the alignment issues automatically right would really be an improvement... > Thanks, > Rusty. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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.24-rc4-git5: Reported regressions from 2.6.23
On Saturday, 8 of December 2007, Andrew Morton wrote:
> On Sat, 8 Dec 2007 09:28:15 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Fabio Comolli <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > > Subject : Battery shows up twice in kpowersave
> > > > Submitter : Rolf Eike Beer <[EMAIL PROTECTED]>
> > > > References : http://bugzilla.kernel.org/show_bug.cgi?id=9494
> > > > Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]>
> > > > Patch :
> > > >
> > >
> > > I don't think that this is a regression: I reported on RedHat bugzilla
> > > when I switched from F7 to F8 and I was using 2.6.23.8 at that time.
> > > It looks to me an HAL regression, but of course I may be wrong :-) as
> > > the reported bisected to a bad commit.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=373041
> > >
> > > By the way, I now switched to Fedrora Rawhide with a 2.6.24-rc4-git5
> > > custom kernel and Gnome desktop and the problem is still present, even
> > > with gnome-power-manager.
> >
> > to me this looks like an ABI regression - utilities should work without
> > change. Something changed in /sys output that caused HAL to think that
> > there are two batteries:
>
> Yep. Although HAL is of course a most special case of "userspace".
>
> > | The output of lshal shows that there are two UDI's with
> > | info.capabilities = { 'battery' }:
> > |
> > | udi = '/org/freedesktop/Hal/devices/acpi_BAT0'
> > | udi = '/org/freedesktop/Hal/devices/computer_power_supply_0'
> >
> > whether it's a HAL bug or a kernel bug, the original state should be
> > restored and it should be worked out without breaking users of older HAL
> > versions.
>
> "breaking users of older HAL versions" == "breaking machines".
>
> The patch should be reverted. Do we know which one it was?
>
> > grumble: way too many times do various system utilities break when i
> > upgrade the kernel on my laptop. Maybe a new debug mechanism: we should
> > start fingerprinting the exact /sys and /proc output and enforce that
> > it's immutable across kernel releases as long as the hardware is
> > unmodified?
>
> That would be neat. It would need to be executed on a lot of different
> machines.
Hm, that wouldn't allow us to add new attributes ...
--
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: ICH9 & Core2 Duo - kernel crash
Bill Davidsen wrote: Pavol Cvengros wrote: Bill Davidsen wrote: Pavol Cvengros wrote: On Thursday 06 December 2007 21:15:53 Bill Davidsen wrote: Pavol Cvengros wrote: Hello, I am trying LKML to get some help on one linux kernel related problem. Lately we got a machine with new HW from Intel. CPU is Intel Core2 Duo E6850 3GHz with 2GB of RAM. Motherboard is Intel DG33BU with G33 chipset. After long fight with kernel crashes on different things, we figured out that if the multicore is disabled in bios, everything is ok and machine is running good. No kernel crashes no problems, but with one core only. This small table will maybe explain: Cores - kernel - state 2 - nonsmp or smp - crash 1 - smp or nonsmp - ok All crashes have been different (swaper, rcu, irq, init.) or we just got internal gcc compiler error while compiling kernel/glibc/ and the machine was frozen. Please can somebody advise what to do to identify that problem more precisely. (debug kernel options?) Our immpresion - ICH9 & ICH9R support in kernel is bad... sorry to say.. I have seen unusual memory behavior under heavy load, in the cases I saw it was heavy DMA load from multiple SCSI controllers, and one case with FFT on the CPU and heavy network load with gigE. Have you run memtest on this hardware? Just a thought, but I see people running Linux on that chipset, if not that particular board. A cheap test even if it shows nothing. Of course it could be a CPU cache issue in that one CPU, although that's unlikely. yes, memtest was running all his tests without problems. The wierd thing is that all kernel crashes we have seen were different (as stated in original mail) The problem with memtest, unless I underestimate it, is that it doesn't use all core and siblings, so it doesn't quite load the memory system the way regular usage would. Needless to say, if this does turn out to be a memory loading issue I don't know of any tools to really test it. I fall back on part swapping, but that only helps if it's the memory DIMM itself. right now that machine has 2 x 1GB DDR2 - 800MHz do you think I should test the machine with only one DDR? (I hope to put there 4GB all together) Well, odd memory problems are rare, did you look for a BIOS update? It could be that the chipset isn't being set properly, and would explain why it might work differently with another BIOS. But if there's nothing else to try, it won't hurt to see if it works differently with only one DDR. original BIOS and the latest BIOS tested, doesn't work I will try latest kernels and just one DDR -- 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 1/6] indirect: use asmlinkage in i386 syscall table prototype
>> +extern asmlinkage long (*sys_call_table[])(long, long, long, > This should be something like below instead, otherwise gcc wont parse > asmlinkage as being an attribute of the function signature. > extern long (asmlinkage *sys_call_table[])(long, long, long, Yeah, thanks for pointing these out. As it happened, Jens beat you to it :). Both problems have been fixed in the git repositories for the guilt series and userspace tools, respectively. You can always fetch the most recent versions from there. - z -- 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: Bug: get EXT3-fs error Allocating block in system zone
Linus Torvalds schrieb: But the disk errors are something else, doesn't ring a bell. Sounds like IO corruption on the group descriptor block or something like that. Might be worth testing to see if the problem goes away with less than 4GB of RAM.. Today, I tested with different amounts of RAM: 2 GB: everything works fine 4 GB: same issue as described before with allocating block in system zone So what to do, in order to use more than 2 Gigs of RAM? Marco -- 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: scsi_wait_scan Kconfig option
> Clemens Koller <[EMAIL PROTECTED]> wrote: >> Nick Warne schrieb: >>> I am bringing this up again - primarily as I forgot about it after >>> patching my build tree ages ago: >>> >>> http://lkml.org/lkml/2007/10/27/68 >> Please see the patch I sent some days ago, which does the very >> same thing: http://marc.info/?l=linux-kernel=119677244318528=2 Besides, in order for scsi_wait_scan to work, drivers need to support it explicitly, don't they? If so, simply kill the "default m" from config SCSI_WAIT_SCAN and let any driver which is integrated with it select it. (Not that I'm a friend of select, but here is a case where it won't hurt too much.) -- Stefan Richter -=-=-=== ==-- -=--- http://arcgraph.de/sr/ -- 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: entropy gathering (was Re: Why does reading from /dev/urandom deplete entropy so much?)
On Sat, Dec 08, 2007 at 02:19:54PM -0600, Matt Mackall wrote:
> On Sat, Dec 08, 2007 at 03:04:32PM -0500, Jeff Garzik wrote:
> > Matt Mackall wrote:
> > >On Sat, Dec 08, 2007 at 02:36:33PM -0500, Jeff Garzik wrote:
> > >>As an aside...
> > >>
> > >>Speaking as the maintainer rng-tools, which is the home of the hardware
> > >>RNG entropy gathering daemon...
> > >>
> > >>I wish somebody (not me) would take rngd and several other projects, and
> > >>combine them into a single actively maintained "entropy gathering"
> > >>package.
> > >
> > >I think we should re-evaluate having an internal path from the hwrngs
> > >to /dev/[u]random, which will reduce the need for userspace config
> > >that can go wrong.
> >
> > That's a bit of a tangent on a tangent. :) Most people don't have a
> > hardware RNG.
> >
> > But as long as there are adequate safeguards against common hardware
> > failures (read: FIPS testing inside the kernel), go for it.
>
> We can do some internal whitening and some other basic tests
> (obviously not the full FIPS battery). The basic von Neumann whitening
> will do a great job of shutting off the spigot when an RNG fails in a
> non-nefarious way. And FIPS stuff is no defense against the nefarious
> failures anyway.
>
> But I think simply dividing our entropy estimate by 10 or so will go
> an awfully long way.
Agreed. The example program you posted does a very good job. I intuitively
thought that it would show best results where CPU clock >>> system clock,
but even with a faster clock (gettimeofday()) and a few tricks, it provides
an excellent whitened output even at high speed. In fact, it has the advantage
of automatically adjusting its speed to the source clock resolution, which
ensures we don't return long runs of zeroes or ones. Here's my slightly
modified version to extract large amounts of data from gettimeofday(),
followed by test results :
#include
#include
#include
int get_clock()
{
struct timeval tv;
unsigned i;
gettimeofday(, NULL);
i = tv.tv_usec ^ tv.tv_sec;
i = (i ^ (i >> 16)) & 0x;
i = (i ^ (i >> 8)) & 0xff;
i = (i ^ (i >> 4)) & 0xf;
i = (i ^ (i >> 2)) & 0x3;
i = (i ^ (i >> 1)) & 0x1;
return i;
}
int get_raw_timing_bit(void)
{
int parity = 0;
int start = get_clock();
while(start == get_clock()) {
parity++;
}
return parity & 1;
}
int get_whitened_timing_bit(void) {
int a, b;
while (1) {
// ensure we restart without the time offset from the
// failed tests.
get_raw_timing_bit();
a = get_raw_timing_bit();
b = get_raw_timing_bit();
if (a > b)
return 1;
if (b > a)
return 0;
}
}
int main(void)
{
int i;
while (1) {
for (i = 0; i < 64; i++) {
int j, k;
// variable-length eating 2N values per bit, looking
// for changing values.
do {
j = get_whitened_timing_bit();
k = get_whitened_timing_bit();
} while (j == k);
printf("%d", j);
}
printf("\n");
}
}
On my athlon 1.5 GHz with HZ=250, it produces about 40 kb/second. On an
IXP420 at 266 MHz with HZ=100, it produces about 6 kb/s. On a VAX VLC4000
at around 60 MHz under openbsd, it produces about 6 bits/s. In all cases,
the output data looks well distributed :
[EMAIL PROTECTED]:~$ for i in entropy.out.*; do echo $i :;z=$(tr -cd '0' <$i|wc
-c); o=$(tr -cd '1' <$i|wc -c); echo $z zeroes, $o ones;done
entropy.out.k7 :
159811 zeroes, 166861 ones
entropy.out.nslu2 :
23786 zeroes, 24610 ones
entropy.out.vax :
687 zeroes, 657 ones
And there are very few long runs, the data is not compressible :
[EMAIL PROTECTED]:~$ for i in entropy.out.*; do echo -n "$i : ";u=$(tr -d '01'
-c <$i|wc -c); c=$(tr -d '01' -c <$i | gzip -c9|wc -c); echo $(echo $u/$c|bc
-l) digits/gzip byte;done
entropy.out.k7 : 6.67672246407913830809 digits/gzip byte
entropy.out.nslu2 : 6.27460132244262932711 digits/gzip byte
entropy.out.vax : 4.74911660777385159010 digits/gzip byte
Here are the 4 first output lines of the k7 version :
010001001100111011100100100011011101010000001000
10110101011010101110111010001011010001101101000101011011
110000100101111101001110101001010110110001111000
01110010100110100010010010111000100100101100011010011100
I found no unique line out of 1. I think the fact that the
clock source used by gettimeofday() is not completely coupled
with the TSC makes this possible. If we had used rdtsc() instead
of gettimeofday(), we might have gotten really strange patterns.
It's possible that
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
> The point here is that Linux is NOT using a defined-to-be "unused" > port. It IS using the "diagnostic" port, and talking to a diagnostic > device that *is* used, and may be present. Just like millions of other pieces of software from the same era. > 2) Start a background task with the maintainers of drivers to clean up > their code regarding these short delays for slow devices (note that it's > never because the *bus* is slow, but because the *device* is slow.) > Perhaps this could be helped by "deprecating" the _p calls and > suggesting an alternative that requires the coder to be precise about > what the delay is for, and how long it is supposed to be, perhaps on a > per-machine basis. Send patches. For a lot of the devices we know what the requirements are as its locked to ISA cycle times. Alan -- 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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Dec 8, 2007 3:51 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > what chipset is this? > (I wonder if there's one where we shouldn't be force-enabling the hpet) It's an Intel Mac Mini - Intel 945GM chipset. I believe OSX requires HPET and so there shouldn't be a need to force enable it on this chipset? Also I don't have problems under Centos 5.1 kernel (2.6.18-53.1.4.el5) and hpet is enabled there. Parag -- 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] asm-*/compat.h: fix typo in comment
asm-*/compat.h: fix typo in comment
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
include/asm-ia64/compat.h|2 +-
include/asm-mips/compat.h|2 +-
include/asm-parisc/compat.h |2 +-
include/asm-powerpc/compat.h |2 +-
include/asm-s390/compat.h|2 +-
include/asm-sparc64/compat.h |2 +-
include/asm-x86/compat.h |2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/asm-ia64/compat.h b/include/asm-ia64/compat.h
index 0f6e526..dfcf75b 100644
--- a/include/asm-ia64/compat.h
+++ b/include/asm-ia64/compat.h
@@ -181,7 +181,7 @@ struct compat_shmid64_ds {
/*
* A pointer passed in from user mode. This should not be used for syscall
parameters,
* just declare them as pointers because the syscall entry code will have
appropriately
- * comverted them already.
+ * converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-mips/compat.h b/include/asm-mips/compat.h
index 568c76c..ac5d541 100644
--- a/include/asm-mips/compat.h
+++ b/include/asm-mips/compat.h
@@ -128,7 +128,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedef u32compat_uptr_t;
diff --git a/include/asm-parisc/compat.h b/include/asm-parisc/compat.h
index 5a85d1b..7f32611 100644
--- a/include/asm-parisc/compat.h
+++ b/include/asm-parisc/compat.h
@@ -132,7 +132,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-powerpc/compat.h b/include/asm-powerpc/compat.h
index 64ab1dd..d811a8c 100644
--- a/include/asm-powerpc/compat.h
+++ b/include/asm-powerpc/compat.h
@@ -119,7 +119,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-s390/compat.h b/include/asm-s390/compat.h
index 7f4ad62..de065b3 100644
--- a/include/asm-s390/compat.h
+++ b/include/asm-s390/compat.h
@@ -149,7 +149,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-sparc64/compat.h b/include/asm-sparc64/compat.h
index 01fe668..f260b58 100644
--- a/include/asm-sparc64/compat.h
+++ b/include/asm-sparc64/compat.h
@@ -152,7 +152,7 @@ typedef u32 compat_sigset_word;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
diff --git a/include/asm-x86/compat.h b/include/asm-x86/compat.h
index 66ba798..0e18cb5 100644
--- a/include/asm-x86/compat.h
+++ b/include/asm-x86/compat.h
@@ -190,7 +190,7 @@ typedef struct user_regs_struct32 compat_elf_gregset_t;
* A pointer passed in from user mode. This should not
* be used for syscall parameters, just declare them
* as pointers because the syscall entry code will have
- * appropriately comverted them already.
+ * appropriately converted them already.
*/
typedefu32 compat_uptr_t;
--
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: lockdep problem conversion semaphore->mutex (dev->sem)
Peter, Thanks for this clear answer. Remy 2007/12/8, Peter Zijlstra <[EMAIL PROTECTED]>: > > On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > > > Which problems? I did not see any special things, it looked rather > > straight forward. What have I overlooked? > > On suspend it locks the whole device tree, this means it has 'unbounded' > nesting and holds an 'unbounded' number of locks. Neither things are > easy to annotate (remember that mutex_lock_nested can handle up to 8 > nestings and current->held_locks has a max of 30). > > In fact, converting this will be the hardest part, it would require > reworking the locking and introduction of a hard limit on the device > tree depth - this might upset some people, but I suspect that 16 or 24 > should be deep enough for pretty much anything. Of course, if people > prove me wrong, I'll have to reconsider. The up-side of the locking > scheme I'm thinking of will be that locking the whole tree will only > take 'depth' number of opterations vs the total number of tree elements. > > > > -- > 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/ > -- 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] sound/core/seq: move declarations of globally visible variables to proper headers
sound/core/seq: move declarations of globally visible variables to proper
headers
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
sound/core/seq/seq_clientmgr.c |2 --
sound/core/seq/seq_clientmgr.h |2 ++
sound/core/seq/seq_timer.c |7 ---
sound/core/seq/seq_timer.h |7 +++
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 2e3fa25..048ad5a 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -130,8 +130,6 @@ static struct snd_seq_client *clientptr(int clientid)
return clienttab[clientid];
}
-extern int seq_client_load[];
-
struct snd_seq_client *snd_seq_client_use_ptr(int clientid)
{
unsigned long flags;
diff --git a/sound/core/seq/seq_clientmgr.h b/sound/core/seq/seq_clientmgr.h
index 5e04e20..20f0a72 100644
--- a/sound/core/seq/seq_clientmgr.h
+++ b/sound/core/seq/seq_clientmgr.h
@@ -98,4 +98,6 @@ int snd_seq_kernel_client_write_poll(int clientid, struct
file *file, poll_table
int snd_seq_client_notify_subscription(int client, int port,
struct snd_seq_port_subscribe *info, int
evtype);
+extern int seq_client_load[15];
+
#endif
diff --git a/sound/core/seq/seq_timer.c b/sound/core/seq/seq_timer.c
index 8716352..82a5b33 100644
--- a/sound/core/seq/seq_timer.c
+++ b/sound/core/seq/seq_timer.c
@@ -27,13 +27,6 @@
#include "seq_queue.h"
#include "seq_info.h"
-extern int seq_default_timer_class;
-extern int seq_default_timer_sclass;
-extern int seq_default_timer_card;
-extern int seq_default_timer_device;
-extern int seq_default_timer_subdevice;
-extern int seq_default_timer_resolution;
-
/* allowed sequencer timer frequencies, in Hz */
#define MIN_FREQUENCY 10
#define MAX_FREQUENCY 6250
diff --git a/sound/core/seq/seq_timer.h b/sound/core/seq/seq_timer.h
index e9ee154..88dfb71 100644
--- a/sound/core/seq/seq_timer.h
+++ b/sound/core/seq/seq_timer.h
@@ -138,4 +138,11 @@ int snd_seq_timer_set_skew(struct snd_seq_timer *tmr,
unsigned int skew, unsigne
snd_seq_real_time_t snd_seq_timer_get_cur_time(struct snd_seq_timer *tmr);
snd_seq_tick_time_t snd_seq_timer_get_cur_tick(struct snd_seq_timer *tmr);
+extern int seq_default_timer_class;
+extern int seq_default_timer_sclass;
+extern int seq_default_timer_card;
+extern int seq_default_timer_device;
+extern int seq_default_timer_subdevice;
+extern int seq_default_timer_resolution;
+
#endif
--
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] sound/core/memory.c: include sound/core.h
sound/core/memory.c: include sound/core.h copy_to_user_fromio and copy_from_user_toio are declared in sound/core.h but sound/core/memory.c doesn't include it - fix it depends on: "[PATCH] sound/core.h: include sound/driver.h" Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]> --- sound/core/memory.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/core/memory.c b/sound/core/memory.c index 25b0f05..0420056 100644 --- a/sound/core/memory.c +++ b/sound/core/memory.c @@ -23,6 +23,7 @@ #include #include #include +#include /** * copy_to_user_fromio - copy data from mmio-space to user-space -- 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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Sat, 8 Dec 2007 15:46:54 -0500 "Parag Warudkar" <[EMAIL PROTECTED]> wrote: > On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > > > But there are still fluctuations under 100% idle - > > > > do you have CONFIG_HIGH_RES_TIMERS=y? > > Yes - NO_HZ=y and HIGH_RES_TIMERS=y. > My ssh connection still died with hpet=disable although this time I > did not see soft lockup message. > Also it randomly gets stuck - suddenly there is a freeze and I can't > type for seconds. > > > these fluctuations would still be OK if they are due to HZ > > granularity. > > > > So are the hpet ones ok too or do they seem off even with HRTIMERS=y? > Just trying to figure out if I should be testing further with hpet > disabled or enabling it is ok. > what chipset is this? (I wonder if there's one where we shouldn't be force-enabling the hpet) -- 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: lockdep problem conversion semaphore->mutex (dev->sem)
On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > Which problems? I did not see any special things, it looked rather > straight forward. What have I overlooked? On suspend it locks the whole device tree, this means it has 'unbounded' nesting and holds an 'unbounded' number of locks. Neither things are easy to annotate (remember that mutex_lock_nested can handle up to 8 nestings and current->held_locks has a max of 30). In fact, converting this will be the hardest part, it would require reworking the locking and introduction of a hard limit on the device tree depth - this might upset some people, but I suspect that 16 or 24 should be deep enough for pretty much anything. Of course, if people prove me wrong, I'll have to reconsider. The up-side of the locking scheme I'm thinking of will be that locking the whole tree will only take 'depth' number of opterations vs the total number of tree elements. -- 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] sound/core.h: include sound/driver.h
sound/core.h: include sound/driver.h include sound/driver.h in sound/core.h because core.h uses SNDRV_CARDS (which is defined in sound/driver.h) Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]> --- include/sound/core.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/sound/core.h b/include/sound/core.h index 6954836..3b0903a 100644 --- a/include/sound/core.h +++ b/include/sound/core.h @@ -27,6 +27,7 @@ #include/* struct rw_semaphore */ #include /* pm_message_t */ #include +#include /* forward declarations */ #ifdef CONFIG_PCI -- 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: entropy gathering (was Re: Why does reading from /dev/urandom deplete entropy so much?)
Theodore Tso wrote: I think the userspace config problems were mainly due to the fact that there wasn't a single official userspace utility package for the random number package. Comments in drivers/char/random.c for how to set up /etc/init.d/random is Just Not Enough. Absolutely. If we had a single, official random number generator package that contained the configuration, init.d script, as well as the daemon that can do all sorts of different things that you really, Really, REALLY want to do in userspace, including: * FIPS testing (as Jeff suggested --- making sure what you think is randomness isn't 60Hz hum is a Really Good Idea :-) * access to TPM (if available --- I have a vague memory that you may need access to the TPM key to access any of its functions, and the the TPM key is stored in the filesystem) +1 agreed (not volunteering, but I will cheer on the hearty soul who undertakes this endeavor...) -- 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: lockdep problem conversion semaphore->mutex (dev->sem)
Hello Ingo, > no, you are wrong. If you want to do complex locking, you can still do > it: take a look at the dev->sem conversion patches from Peter which > correctly do this. Lockdep has all the facilities for that. > (you just dont know about them) Ok. > the general policy message here is: do not implement complex locking. It > hurts. It's hard to maintain. It's easy to mess up and leads to bugs. Agree > Lockdep just makes that plain obvious. > Your mail and your frustration shows this general concept in happy Please, do not see it as frustration, because it isn't... I just want to understand it better. > action: judging from your comments you have little clue about dev->sem > locking and its implications and you'd happily go along and pollute the > kernel with complex and hard to maintain nested locking constructs. Now, you assume that i would _like_ complex locking. This is not true. I just want to understand what was so wrong with dev->sem, I even read in the discussions before about dev->sem, that it still was on the old semaphore interface to get around lockdep issues, and _that_ is wrong. That is bug-hiding from either the code or the tool. I just wanted to understand if this was a lockdep bug, or a real code bug. > Lockdep prevents you from doing it mindlessly, it _forces_ you to first > understand the data structures, their locking and their relationship > with each other. Then you can implement complexity, if you still want > it. > > That, Sir, is a Good Thing (tm). Completely agree. Remy -- 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: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
I am going to do a test on another "unused" port. However, I realized as I was thinking about this. 0x80 is the "diagnostic device" port. It is not an "unused" port. Normally, Linux would support a device like the diagnostic device by providing a character device, called /dev/post-diagnosis (for the power-on test diagnostic). That device would reserve port 80 for its use, and the driver could be loaded if there was such a device. Now one possibility is that my laptop contains a diagnostic code device that stores all the out's to port 80 (documented only to the designers, and kept "secret"). That device may need "clearing" periodically, which is perhaps done by the SMM, which is turned off when I go into ACPI-on state. Or maybe it is designed to be cleared only when the system boots at the beginning of the BIOS. What happens when (as happens in hwclock's polling of the RTC) thousands of in/out*_p calls are made very fast? Well, perhaps it is not cleared quickly enough, and hangs the bus. The point here is that Linux is NOT using a defined-to-be "unused" port. It IS using the "diagnostic" port, and talking to a diagnostic device that *is* used, and may be present. Just doesn't seem clean to me. So I'd suggest 2 actions: 1) figure out a better implementation of _p that is "safe" and doesn't use questionable heuristics. udelay seems reasonable because it doesn't drive contention on the busses on SMP machines, but perhaps someone has a better idea. 2) Start a background task with the maintainers of drivers to clean up their code regarding these short delays for slow devices (note that it's never because the *bus* is slow, but because the *device* is slow.) Perhaps this could be helped by "deprecating" the _p calls and suggesting an alternative that requires the coder to be precise about what the delay is for, and how long it is supposed to be, perhaps on a per-machine basis. -- 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: soft lockup - CPU#1 stuck for 15s! [swapper:0]
On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Parag Warudkar <[EMAIL PROTECTED]> wrote: > > > But there are still fluctuations under 100% idle - > > do you have CONFIG_HIGH_RES_TIMERS=y? Yes - NO_HZ=y and HIGH_RES_TIMERS=y. My ssh connection still died with hpet=disable although this time I did not see soft lockup message. Also it randomly gets stuck - suddenly there is a freeze and I can't type for seconds. > these fluctuations would still be OK if they are due to HZ granularity. > So are the hpet ones ok too or do they seem off even with HRTIMERS=y? Just trying to figure out if I should be testing further with hpet disabled or enabling it is ok. Parag -- 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 2/2] Unionfs: reduce the amount of cache-coherency debugging messages
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/dentry.c | 38 +++---
1 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 05d9914..7d27987 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -195,9 +195,11 @@ out:
* file system doesn't change its inode times quick enough, resulting in a
* false positive indication (which is harmless, it just makes unionfs do
* extra work in re-validating the objects). To minimize the chances of
- * these situations, we delay the detection of changed times by
- * UNIONFS_MIN_CC_TIME (which defaults to 3 seconds, as with NFS's
- * acregmin).
+ * these situations, we still consider such small time changes valid, but we
+ * don't print debugging messages unless the time changes are greater than
+ * UNIONFS_MIN_CC_TIME (which defaults to 3 seconds, as with NFS's acregmin)
+ * because significant changes are more likely due to users manually
+ * touching lower files.
*/
bool is_newer_lower(const struct dentry *dentry)
{
@@ -219,20 +221,26 @@ bool is_newer_lower(const struct dentry *dentry)
continue;
/* check if mtime/ctime have changed */
- if (unlikely((lower_inode->i_mtime.tv_sec -
- inode->i_mtime.tv_sec) > UNIONFS_MIN_CC_TIME)) {
- pr_info("unionfs: new lower inode mtime "
- "(bindex=%d, name=%s)\n", bindex,
- dentry->d_name.name);
- show_dinode_times(dentry);
+ if (unlikely(timespec_compare(>i_mtime,
+ _inode->i_mtime) < 0)) {
+ if ((lower_inode->i_mtime.tv_sec -
+inode->i_mtime.tv_sec) > UNIONFS_MIN_CC_TIME) {
+ pr_info("unionfs: new lower inode mtime "
+ "(bindex=%d, name=%s)\n", bindex,
+ dentry->d_name.name);
+ show_dinode_times(dentry);
+ }
return true;
}
- if (unlikely((lower_inode->i_ctime.tv_sec -
- inode->i_ctime.tv_sec) > UNIONFS_MIN_CC_TIME)) {
- pr_info("unionfs: new lower inode ctime "
- "(bindex=%d, name=%s)\n", bindex,
- dentry->d_name.name);
- show_dinode_times(dentry);
+ if (unlikely(timespec_compare(>i_ctime,
+ _inode->i_ctime) < 0)) {
+ if ((lower_inode->i_ctime.tv_sec -
+inode->i_ctime.tv_sec) > UNIONFS_MIN_CC_TIME) {
+ pr_info("unionfs: new lower inode ctime "
+ "(bindex=%d, name=%s)\n", bindex,
+ dentry->d_name.name);
+ show_dinode_times(dentry);
+ }
return true;
}
}
--
1.5.2.2
--
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 1/2] Unionfs: cleanup/consolidate branch-mode parsing code
Also a bug fix: disallow unrecognized branch modes at mount time, instead of
defaulting to "rw".
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/main.c | 44 ++--
fs/unionfs/super.c | 12
fs/unionfs/union.h |3 +--
3 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index ffb0da1..22aa6e6 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -256,30 +256,21 @@ static int is_branch_overlap(struct dentry *dent1, struct
dentry *dent2)
}
/*
- * Parse branch mode helper function
+ * Parse "ro" or "rw" options, but default to "rw" if no mode options was
+ * specified. Fill the mode bits in @perms. If encounter an unknown
+ * string, return -EINVAL. Otherwise return 0.
*/
-int __parse_branch_mode(const char *name)
+int parse_branch_mode(const char *name, int *perms)
{
- if (!name)
+ if (!name || !strcmp(name, "rw")) {
+ *perms = MAY_READ | MAY_WRITE;
return 0;
- if (!strcmp(name, "ro"))
- return MAY_READ;
- if (!strcmp(name, "rw"))
- return (MAY_READ | MAY_WRITE);
- return 0;
-}
-
-/*
- * Parse "ro" or "rw" options, but default to "rw" of no mode options
- * was specified.
- */
-int parse_branch_mode(const char *name)
-{
- int perms = __parse_branch_mode(name);
-
- if (perms == 0)
- perms = MAY_READ | MAY_WRITE;
- return perms;
+ }
+ if (!strcmp(name, "ro")) {
+ *perms = MAY_READ;
+ return 0;
+ }
+ return -EINVAL;
}
/*
@@ -350,8 +341,17 @@ static int parse_dirs_option(struct super_block *sb,
struct unionfs_dentry_info
if (mode)
*mode++ = '\0';
- perms = parse_branch_mode(mode);
+ err = parse_branch_mode(mode, );
+ if (err) {
+ printk(KERN_ERR "unionfs: invalid mode \"%s\" for "
+ "branch %d\n", mode, bindex);
+ goto out;
+ }
+ /* ensure that leftmost branch is writeable */
if (!bindex && !(perms & MAY_WRITE)) {
+ printk(KERN_ERR "unionfs: leftmost branch cannot be "
+ "read-only (use \"-o ro\" to create a "
+ "read-only union)\n");
err = -EINVAL;
goto out;
}
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 88f77d7..d9cf2a7 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -181,8 +181,8 @@ static noinline int do_remount_mode_option(char *optarg,
int cur_branches,
goto out;
}
*modename++ = '\0';
- perms = __parse_branch_mode(modename);
- if (perms == 0) {
+ err = parse_branch_mode(modename, );
+ if (err) {
printk(KERN_ERR "unionfs: invalid mode \"%s\" for \"%s\"\n",
modename, optarg);
goto out;
@@ -350,13 +350,17 @@ found_insertion_point:
modename = strchr(new_branch, '=');
if (modename)
*modename++ = '\0';
- perms = parse_branch_mode(modename);
-
if (!new_branch || !*new_branch) {
printk(KERN_ERR "unionfs: null new branch\n");
err = -EINVAL;
goto out;
}
+ err = parse_branch_mode(modename, );
+ if (err) {
+ printk(KERN_ERR "unionfs: invalid mode \"%s\" for "
+ "branch \"%s\"\n", modename, new_branch);
+ goto out;
+ }
err = path_lookup(new_branch, LOOKUP_FOLLOW, );
if (err) {
printk(KERN_ERR "unionfs: error accessing "
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 283b085..20bff7b 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -474,8 +474,7 @@ static inline int is_robranch(const struct dentry *dentry)
*/
extern char *alloc_whname(const char *name, int len);
extern int check_branch(struct nameidata *nd);
-extern int __parse_branch_mode(const char *name);
-extern int parse_branch_mode(const char *name);
+extern int parse_branch_mode(const char *name, int *perms);
/*
* These two functions are here because it is kind of daft to copy and paste
--
1.5.2.2
--
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/
[GIT PULL -mm] 0/2 Unionfs updates/fixes/cleanups
The following is a series of patches related to Unionfs: just a couple of
small bug fixes and/or optimizations.
These patches were tested (where appropriate) on Linus's 2.6.24 latest code
(as of v2.6.24-rc4-124-gf194d13), MM, as well as the backports to
2.6.{23,22,21,20,19,18,9} on ext2/3/4, xfs, reiserfs, nfs2/3/4, jffs2,
ramfs, tmpfs, cramfs, and squashfs (where available). See
http://unionfs.filesystems.org/ to download back-ported unionfs code.
Please pull from the 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/ezk/unionfs.git
to receive the following:
Erez Zadok (2):
Unionfs: cleanup/consolidate branch-mode parsing code
Unionfs: reduce the amount of cache-coherency debugging messages
dentry.c | 38 +++---
main.c | 44 ++--
super.c | 12
union.h |3 +--
4 files changed, 54 insertions(+), 43 deletions(-)
---
Erez Zadok
[EMAIL PROTECTED]
--
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] info_oss: move prototype of snd_card_info_read_oss to info.h
info_oss: move prototype of snd_card_info_read_oss to info.h
Signed-off-by: Marcin Ślusarz <[EMAIL PROTECTED]>
---
include/sound/info.h |2 ++
sound/core/info_oss.c |2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/sound/info.h b/include/sound/info.h
index fecbb1f..8ae72e7 100644
--- a/include/sound/info.h
+++ b/include/sound/info.h
@@ -100,8 +100,10 @@ int snd_info_minor_unregister(void);
extern struct snd_info_entry *snd_seq_root;
#ifdef CONFIG_SND_OSSEMUL
extern struct snd_info_entry *snd_oss_root;
+void snd_card_info_read_oss(struct snd_info_buffer *buffer);
#else
#define snd_oss_root NULL
+static inline void snd_card_info_read_oss(struct snd_info_buffer *buffer) {}
#endif
int snd_iprintf(struct snd_info_buffer * buffer, char *fmt,...) __attribute__
((format (printf, 2, 3)));
diff --git a/sound/core/info_oss.c b/sound/core/info_oss.c
index 435c939..9e8b816 100644
--- a/sound/core/info_oss.c
+++ b/sound/core/info_oss.c
@@ -66,8 +66,6 @@ int snd_oss_info_register(int dev, int num, char *string)
EXPORT_SYMBOL(snd_oss_info_register);
-extern void snd_card_info_read_oss(struct snd_info_buffer *buffer);
-
static int snd_sndstat_show_strings(struct snd_info_buffer *buf, char *id, int
dev)
{
int idx, ok = -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: use of fixmap on non-x86/sh?
On Fri, Nov 30, 2007 at 04:14:55PM -0600, Kumar Gala wrote: > Ben and I are talking about using fixmap on ppc for similar applications to > it use on x86. However in poking around other arch's (sparc, mips) they > appear to have some support but not as complete as x86. > > For example both SPARC & MIPS reference __set_fixmap() in asm/fixmap.h but > I can't find an implementation on either. > > So I was wondering if there was some reason fixmap isn't as well supported > or if its just used for a specific function on those SPARC, MIPS, etc. and > they dont need as much functionality out of it as x86 does. MIPS uses fixmap for two purposes: o In some cases it is possibly to avoid or optimize a cacheflush by creating a temporary mapping. The mechanism works very similar to what x86 and MIPS use for atomic kmaps. o Highmem. Both manipulate pagetables directly or even insert entries directly into the TLB without pagetables as intermediate stage so __set_fixmap is indeed unused. Ralf -- 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: entropy gathering (was Re: Why does reading from /dev/urandom deplete entropy so much?)
On Sat, Dec 08, 2007 at 02:36:33PM -0500, Jeff Garzik wrote: > > As an aside... > > Speaking as the maintainer rng-tools, which is the home of the hardware > RNG entropy gathering daemon... > > I wish somebody (not me) would take rngd and several other projects, and > combine them into a single actively maintained "entropy gathering" package. > > IMO entropy gathering has been a long-standing need for headless network > servers (and now virtual machines). > > In addition to rngd for hardware RNGs, I've been daemons out there that > gather from audio and video sources (generally open wires/channels with > nothing plugged in), thermal sources, etc. There is a lot of entropy > that could be gathered via userland, if you think creatively. I remember having installed openssh on an AIX machines years ago, and being amazed by the number of sources it collected entropy from. Simple commands such as "ifconfig -a", "netstat -i" and "du -a", "ps -ef", "w" provided a lot of entropy. Regards, Willy -- 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/
