Re: Disabling in-memory write cache for x86-64 in Linux II
El Sábado, 26 de octubre de 2013 00:32:25 Fengguang Wu escribió: > What's the kernel you are running? And it's writing to a hard disk? > The stalls are most likely caused by either one of > > 1) write IO starves read IO > 2) direct page reclaim blocked when >- trying to writeout PG_dirty pages >- trying to lock PG_writeback pages > > Which may be confirmed by running > > ps -eo ppid,pid,user,stat,pcpu,comm,wchan:32 > or > echo w > /proc/sysrq-trigger# and check dmesg > > during the stalls. The latter command works more reliably. Sorry for the delay (background: rsync'ing large files from/to a hard disk in a desktop with 16GB of RAM makes the whole desktop unreponsive) I just triggered it today (running 3.12), and run sysrq-w: [ 5547.001505] SysRq : Show Blocked State [ 5547.001509] taskPC stack pid father [ 5547.001516] btrfs-transacti D 880425d7a8a0 0 193 2 0x [ 5547.001519] 880425eede10 0002 880425eedfd8 00012e40 [ 5547.001521] 880425eedfd8 00012e40 880425d7a8a0 ea00104baa80 [ 5547.001523] 880425eedd90 880425eedd68 880425eedd70 81080edd [ 5547.001525] Call Trace: [ 5547.001530] [] ? get_parent_ip+0xd/0x50 [ 5547.001533] [] ? sub_preempt_count+0x49/0x50 [ 5547.001535] [] ? _raw_spin_unlock+0x16/0x40 [ 5547.001552] [] ? btrfs_run_ordered_operations+0x212/0x2c0 [btrfs] [ 5547.001554] [] ? get_parent_ip+0xd/0x50 [ 5547.001556] [] ? sub_preempt_count+0x49/0x50 [ 5547.001557] [] ? _raw_spin_unlock_irqrestore+0x26/0x60 [ 5547.001559] [] schedule+0x29/0x70 [ 5547.001566] [] btrfs_commit_transaction+0x265/0x9d0 [btrfs] [ 5547.001569] [] ? wake_up_atomic_t+0x30/0x30 [ 5547.001575] [] transaction_kthread+0x19d/0x220 [btrfs] [ 5547.001581] [] ? free_fs_root+0xc0/0xc0 [btrfs] [ 5547.001583] [] kthread+0xc0/0xd0 [ 5547.001585] [] ? kthread_create_on_node+0x120/0x120 [ 5547.001587] [] ret_from_fork+0x7c/0xb0 [ 5547.001588] [] ? kthread_create_on_node+0x120/0x120 [ 5547.001590] systemd-journal D 880426e19860 0 234 1 0x [ 5547.001592] 880426d77d90 0002 880426d77fd8 00012e40 [ 5547.001593] 880426d77fd8 00012e40 880426e19860 8155d7cd [ 5547.001595] 0001 0001 81572560 [ 5547.001596] Call Trace: [ 5547.001598] [] ? retint_restore_args+0xe/0xe [ 5547.001601] [] ? queue_unplugged+0x3b/0xe0 [ 5547.001602] [] ? blk_flush_plug_list+0x1eb/0x230 [ 5547.001604] [] schedule+0x29/0x70 [ 5547.001606] [] schedule_preempt_disabled+0x18/0x30 [ 5547.001607] [] __mutex_lock_slowpath+0x124/0x1f0 [ 5547.001613] [] ? btrfs_write_marked_extents+0xbb/0xe0 [btrfs] [ 5547.001615] [] mutex_lock+0x17/0x30 [ 5547.001623] [] btrfs_sync_log+0x22a/0x690 [btrfs] [ 5547.001630] [] btrfs_sync_file+0x287/0x2e0 [btrfs] [ 5547.001632] [] do_fsync+0x56/0x80 [ 5547.001634] [] SyS_fsync+0x10/0x20 [ 5547.001635] [] tracesys+0xdd/0xe2 [ 5547.001644] mysqld D 8803f0901860 0 643579 0x [ 5547.001645] 8803f090de18 0002 8803f090dfd8 00012e40 [ 5547.001647] 8803f090dfd8 00012e40 8803f0901860 88016d038000 [ 5547.001648] 880426908d00 24119d80 [ 5547.001650] Call Trace: [ 5547.001657] [] ? btrfs_submit_bio_hook+0x84/0x1f0 [btrfs] [ 5547.001659] [] ? get_parent_ip+0xd/0x50 [ 5547.001660] [] ? sub_preempt_count+0x49/0x50 [ 5547.001662] [] ? _raw_spin_unlock_irqrestore+0x26/0x60 [ 5547.001663] [] schedule+0x29/0x70 [ 5547.001669] [] wait_current_trans.isra.17+0xbf/0x120 [btrfs] [ 5547.001671] [] ? wake_up_atomic_t+0x30/0x30 [ 5547.001677] [] start_transaction+0x37f/0x570 [btrfs] [ 5547.001680] [] ? do_writepages+0x1e/0x40 [ 5547.001686] [] btrfs_start_transaction+0x1b/0x20 [btrfs] [ 5547.001693] [] btrfs_sync_file+0x17f/0x2e0 [btrfs] [ 5547.001694] [] do_fsync+0x56/0x80 [ 5547.001696] [] SyS_fdatasync+0x13/0x20 [ 5547.001697] [] tracesys+0xdd/0xe2 [ 5547.001701] virtuoso-t D 88000310b0c0 0 617609 0x [ 5547.001702] 8803f4867c20 0002 8803f4867fd8 00012e40 [ 5547.001704] 8803f4867fd8 00012e40 88000310b0c0 813ce4af [ 5547.001705] 81860520 8802d8ad8a00 8803f4867ba0 81231a0e [ 5547.001707] Call Trace: [ 5547.001709] [] ? scsi_pool_alloc_command+0x3f/0x80 [ 5547.001712] [] ? __blk_segment_map_sg+0x4e/0x120 [ 5547.001713] [] ? blk_rq_map_sg+0x8b/0x1f0 [ 5547.001716] [] ? cfq_dispatch_requests+0xba/0xc40 [ 5547.001718] [] ? get_parent_ip+0xd/0x50 [ 5547.001721] [] ? filemap_fdatawait+0x30/0x30 [ 5547.001722] [] schedule+0x29/0x70 [ 5547.001723] [] io_schedule+0x8f/0xe0 [ 5547.001725] [] sleep_on_page+0xe/0x20 [ 5547.001727] [] __wait_on_bit+0x62/0x90 [ 5547.001728] [] wait_on_page_bit+0x7f/0x90 [
Re: Disabling in-memory write cache for x86-64 in Linux II
El Sábado, 26 de octubre de 2013 00:32:25 Fengguang Wu escribió: What's the kernel you are running? And it's writing to a hard disk? The stalls are most likely caused by either one of 1) write IO starves read IO 2) direct page reclaim blocked when - trying to writeout PG_dirty pages - trying to lock PG_writeback pages Which may be confirmed by running ps -eo ppid,pid,user,stat,pcpu,comm,wchan:32 or echo w /proc/sysrq-trigger# and check dmesg during the stalls. The latter command works more reliably. Sorry for the delay (background: rsync'ing large files from/to a hard disk in a desktop with 16GB of RAM makes the whole desktop unreponsive) I just triggered it today (running 3.12), and run sysrq-w: [ 5547.001505] SysRq : Show Blocked State [ 5547.001509] taskPC stack pid father [ 5547.001516] btrfs-transacti D 880425d7a8a0 0 193 2 0x [ 5547.001519] 880425eede10 0002 880425eedfd8 00012e40 [ 5547.001521] 880425eedfd8 00012e40 880425d7a8a0 ea00104baa80 [ 5547.001523] 880425eedd90 880425eedd68 880425eedd70 81080edd [ 5547.001525] Call Trace: [ 5547.001530] [81080edd] ? get_parent_ip+0xd/0x50 [ 5547.001533] [81560ed9] ? sub_preempt_count+0x49/0x50 [ 5547.001535] [8155cc86] ? _raw_spin_unlock+0x16/0x40 [ 5547.001552] [a008a742] ? btrfs_run_ordered_operations+0x212/0x2c0 [btrfs] [ 5547.001554] [81080edd] ? get_parent_ip+0xd/0x50 [ 5547.001556] [81560ed9] ? sub_preempt_count+0x49/0x50 [ 5547.001557] [8155d006] ? _raw_spin_unlock_irqrestore+0x26/0x60 [ 5547.001559] [8155b719] schedule+0x29/0x70 [ 5547.001566] [a0072215] btrfs_commit_transaction+0x265/0x9d0 [btrfs] [ 5547.001569] [81073d20] ? wake_up_atomic_t+0x30/0x30 [ 5547.001575] [a006982d] transaction_kthread+0x19d/0x220 [btrfs] [ 5547.001581] [a0069690] ? free_fs_root+0xc0/0xc0 [btrfs] [ 5547.001583] [81072e70] kthread+0xc0/0xd0 [ 5547.001585] [81072db0] ? kthread_create_on_node+0x120/0x120 [ 5547.001587] [81564bac] ret_from_fork+0x7c/0xb0 [ 5547.001588] [81072db0] ? kthread_create_on_node+0x120/0x120 [ 5547.001590] systemd-journal D 880426e19860 0 234 1 0x [ 5547.001592] 880426d77d90 0002 880426d77fd8 00012e40 [ 5547.001593] 880426d77fd8 00012e40 880426e19860 8155d7cd [ 5547.001595] 0001 0001 81572560 [ 5547.001596] Call Trace: [ 5547.001598] [8155d7cd] ? retint_restore_args+0xe/0xe [ 5547.001601] [8122b47b] ? queue_unplugged+0x3b/0xe0 [ 5547.001602] [8122da9b] ? blk_flush_plug_list+0x1eb/0x230 [ 5547.001604] [8155b719] schedule+0x29/0x70 [ 5547.001606] [8155bb88] schedule_preempt_disabled+0x18/0x30 [ 5547.001607] [8155a2f4] __mutex_lock_slowpath+0x124/0x1f0 [ 5547.001613] [a0071c9b] ? btrfs_write_marked_extents+0xbb/0xe0 [btrfs] [ 5547.001615] [8155a3d7] mutex_lock+0x17/0x30 [ 5547.001623] [a00ae06a] btrfs_sync_log+0x22a/0x690 [btrfs] [ 5547.001630] [a0082f47] btrfs_sync_file+0x287/0x2e0 [btrfs] [ 5547.001632] [811abb96] do_fsync+0x56/0x80 [ 5547.001634] [811abe20] SyS_fsync+0x10/0x20 [ 5547.001635] [81564e5f] tracesys+0xdd/0xe2 [ 5547.001644] mysqld D 8803f0901860 0 643579 0x [ 5547.001645] 8803f090de18 0002 8803f090dfd8 00012e40 [ 5547.001647] 8803f090dfd8 00012e40 8803f0901860 88016d038000 [ 5547.001648] 880426908d00 24119d80 [ 5547.001650] Call Trace: [ 5547.001657] [a0074d14] ? btrfs_submit_bio_hook+0x84/0x1f0 [btrfs] [ 5547.001659] [81080edd] ? get_parent_ip+0xd/0x50 [ 5547.001660] [81560ed9] ? sub_preempt_count+0x49/0x50 [ 5547.001662] [8155d006] ? _raw_spin_unlock_irqrestore+0x26/0x60 [ 5547.001663] [8155b719] schedule+0x29/0x70 [ 5547.001669] [a007170f] wait_current_trans.isra.17+0xbf/0x120 [btrfs] [ 5547.001671] [81073d20] ? wake_up_atomic_t+0x30/0x30 [ 5547.001677] [a0072cff] start_transaction+0x37f/0x570 [btrfs] [ 5547.001680] [8112632e] ? do_writepages+0x1e/0x40 [ 5547.001686] [a0072f0b] btrfs_start_transaction+0x1b/0x20 [btrfs] [ 5547.001693] [a0082e3f] btrfs_sync_file+0x17f/0x2e0 [btrfs] [ 5547.001694] [811abb96] do_fsync+0x56/0x80 [ 5547.001696] [811abe43] SyS_fdatasync+0x13/0x20 [ 5547.001697] [81564e5f] tracesys+0xdd/0xe2 [ 5547.001701] virtuoso-t D 88000310b0c0 0 617609 0x [ 5547.001702] 8803f4867c20 0002 8803f4867fd8 00012e40 [ 5547.001704] 8803f4867fd8
Re: Disabling in-memory write cache for x86-64 in Linux II
El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió: > Oct 25, 2013 05:26:45 PM, david wrote: > >actually, I think the problem is more the impact of the huge write later > >on. > Exactly. And not being able to use applications which show you IO > performance like Midnight Commander. You might prefer to use "cp -a" but I > cannot imagine my life without being able to see the progress of a copying > operation. With the current dirty cache there's no way to understand how > you storage media actually behaves. This is a problem I also have been suffering for a long time. It's not so much how much and when the systems syncs dirty data, but how unreponsive the desktop becomes when it happens (usually, with rsync + large files). Most programs become completely unreponsive, specially if they have a large memory consumption (ie. the browser). I need to pause rsync and wait until the systems writes out all dirty data if I want to do simple things like scrolling or do any action that uses I/O, otherwise I need to wait minutes. I have 16 GB of RAM and excluding the browser (which usually uses about half of a GB) and KDE itself, there are no memory hogs, so it seem like it's something that shouldn't happen. I can understand that I/O operations are laggy when there is some other intensive I/O ongoing, but right now the system becomes completely unreponsive. If I am unlucky and Konsole also becomes unreponsive, I need to switch to a VT (which also takes time). I haven't reported it before in part because I didn't know how to do it, "my browser stalls" is not a very useful description and I didn't know what kind of data I'm supposed to report. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling in-memory write cache for x86-64 in Linux II
El Viernes, 25 de octubre de 2013 18:26:23 Artem S. Tashkinov escribió: Oct 25, 2013 05:26:45 PM, david wrote: actually, I think the problem is more the impact of the huge write later on. Exactly. And not being able to use applications which show you IO performance like Midnight Commander. You might prefer to use cp -a but I cannot imagine my life without being able to see the progress of a copying operation. With the current dirty cache there's no way to understand how you storage media actually behaves. This is a problem I also have been suffering for a long time. It's not so much how much and when the systems syncs dirty data, but how unreponsive the desktop becomes when it happens (usually, with rsync + large files). Most programs become completely unreponsive, specially if they have a large memory consumption (ie. the browser). I need to pause rsync and wait until the systems writes out all dirty data if I want to do simple things like scrolling or do any action that uses I/O, otherwise I need to wait minutes. I have 16 GB of RAM and excluding the browser (which usually uses about half of a GB) and KDE itself, there are no memory hogs, so it seem like it's something that shouldn't happen. I can understand that I/O operations are laggy when there is some other intensive I/O ongoing, but right now the system becomes completely unreponsive. If I am unlucky and Konsole also becomes unreponsive, I need to switch to a VT (which also takes time). I haven't reported it before in part because I didn't know how to do it, my browser stalls is not a very useful description and I didn't know what kind of data I'm supposed to report. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG?: "Cannot map mmconfig aperture"
El Thu, 21 Feb 2008 21:26:56 +0100 (CET), Thomas Gleixner <[EMAIL PROTECTED]> escribió: > Thanks. Nothing new there. Can you please apply the patch below and > provide the output of the ioremap code ? [0.155485] ACPI: bus type pci registered [0.155581] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support. [0.160814] ioremap: CPA e000 268435456 -12 [0.162182] PCI: Cannot map mmconfig aperture for segment 0 [0.162215] PCI: Using configuration type 1 [0.166956] ACPI: EC: Look up EC in DSDT [0.173445] ACPI: Interpreter enabled -- 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?: Cannot map mmconfig aperture
El Thu, 21 Feb 2008 21:26:56 +0100 (CET), Thomas Gleixner [EMAIL PROTECTED] escribió: Thanks. Nothing new there. Can you please apply the patch below and provide the output of the ioremap code ? [0.155485] ACPI: bus type pci registered [0.155581] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support. [0.160814] ioremap: CPA e000 268435456 -12 [0.162182] PCI: Cannot map mmconfig aperture for segment 0 [0.162215] PCI: Using configuration type 1 [0.166956] ACPI: EC: Look up EC in DSDT [0.173445] ACPI: Interpreter enabled -- 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?: "Cannot map mmconfig aperture"
El Thu, 21 Feb 2008 08:53:39 +0100 (CET), Thomas Gleixner <[EMAIL PROTECTED]> escribió: > Hmm, that's confusing. Can you please provide a complete boot log ? > > Thanks, Sure [0.00] Linux version 2.6.25-rc2-00342-g5d9c4a7 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #17 SMP PREEMPT Wed Feb 20 19:54:40 CET 2008 [0.00] Command line: root=/dev/sda2 ro quiet splash locale=es_ES [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3f79 (usable) [0.00] BIOS-e820: 3f79 - 3f79e000 (ACPI data) [0.00] BIOS-e820: 3f79e000 - 3f7e (ACPI NVS) [0.00] BIOS-e820: 3f7e - 3f80 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 259984) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP 000FB0D0, 0024 (r2 ACPIAM) [0.00] ACPI: XSDT 3F790100, 004C (r1 A_M_I_ OEMXSDT 6000706 MSFT 97) [0.00] ACPI: FACP 3F790290, 00F4 (r3 A_M_I_ OEMFACP 6000706 MSFT 97) [0.00] ACPI: DSDT 3F790590, 5870 (r1 A0356 A0356034 34 INTL 20060113) [0.00] ACPI: FACS 3F79E000, 0040 [0.00] ACPI: APIC 3F790390, 0080 (r1 A_M_I_ OEMAPIC 6000706 MSFT 97) [0.00] ACPI: OEMB 3F79E040, 006B (r1 A_M_I_ AMI_OEM 6000706 MSFT 97) [0.00] ACPI: HPET 3F795E00, 0038 (r1 A_M_I_ OEMHPET 6000706 MSFT 97) [0.00] ACPI: MCFG 3F795E40, 003C (r1 A_M_I_ OEMMCFG 6000706 MSFT 97) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 259984) 1 entries of 256 used [0.00] early res: 0 [0-fff] BIOS data page [0.00] early res: 1 [6000-7fff] SMP_TRAMPOLINE [0.00] early res: 2 [20-7d0c57] TEXT DATA BSS [0.00] early res: 3 [9fc00-a0bff] EBDA [0.00] early res: 4 [8000-afff] PGTABLE [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 259984 [0.00] On node 0 totalpages: 259887 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1497 pages reserved [0.00] DMA zone: 2446 pages, LIFO batch:0 [0.00] DMA32 zone: 3498 pages used for memmap [0.00] DMA32 zone: 252390 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to flat [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] Using ACPI (MADT) for SMP configuration information [0.00] PM: Registered nosave memory: 0009f000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e4000 [0.00] PM: Registered nosave memory: 000e4000 - 0010 [0.00] Allocating PCI resources starting at 4000 (gap: 3f80:c078) [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] PERCPU: Allocating 34692 bytes of per cpu data [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 254836 [0.00] Kernel command line: root=/dev/sda2 ro quiet splash locale=es_ES [0.00] Initializing
Re: BUG?: Cannot map mmconfig aperture
El Thu, 21 Feb 2008 08:53:39 +0100 (CET), Thomas Gleixner [EMAIL PROTECTED] escribió: Hmm, that's confusing. Can you please provide a complete boot log ? Thanks, Sure [0.00] Linux version 2.6.25-rc2-00342-g5d9c4a7 ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #17 SMP PREEMPT Wed Feb 20 19:54:40 CET 2008 [0.00] Command line: root=/dev/sda2 ro quiet splash locale=es_ES [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3f79 (usable) [0.00] BIOS-e820: 3f79 - 3f79e000 (ACPI data) [0.00] BIOS-e820: 3f79e000 - 3f7e (ACPI NVS) [0.00] BIOS-e820: 3f7e - 3f80 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 259984) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP 000FB0D0, 0024 (r2 ACPIAM) [0.00] ACPI: XSDT 3F790100, 004C (r1 A_M_I_ OEMXSDT 6000706 MSFT 97) [0.00] ACPI: FACP 3F790290, 00F4 (r3 A_M_I_ OEMFACP 6000706 MSFT 97) [0.00] ACPI: DSDT 3F790590, 5870 (r1 A0356 A0356034 34 INTL 20060113) [0.00] ACPI: FACS 3F79E000, 0040 [0.00] ACPI: APIC 3F790390, 0080 (r1 A_M_I_ OEMAPIC 6000706 MSFT 97) [0.00] ACPI: OEMB 3F79E040, 006B (r1 A_M_I_ AMI_OEM 6000706 MSFT 97) [0.00] ACPI: HPET 3F795E00, 0038 (r1 A_M_I_ OEMHPET 6000706 MSFT 97) [0.00] ACPI: MCFG 3F795E40, 003C (r1 A_M_I_ OEMMCFG 6000706 MSFT 97) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 259984) 1 entries of 256 used [0.00] early res: 0 [0-fff] BIOS data page [0.00] early res: 1 [6000-7fff] SMP_TRAMPOLINE [0.00] early res: 2 [20-7d0c57] TEXT DATA BSS [0.00] early res: 3 [9fc00-a0bff] EBDA [0.00] early res: 4 [8000-afff] PGTABLE [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 259984 [0.00] On node 0 totalpages: 259887 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1497 pages reserved [0.00] DMA zone: 2446 pages, LIFO batch:0 [0.00] DMA32 zone: 3498 pages used for memmap [0.00] DMA32 zone: 252390 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to flat [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] Using ACPI (MADT) for SMP configuration information [0.00] PM: Registered nosave memory: 0009f000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e4000 [0.00] PM: Registered nosave memory: 000e4000 - 0010 [0.00] Allocating PCI resources starting at 4000 (gap: 3f80:c078) [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] PERCPU: Allocating 34692 bytes of per cpu data [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 254836 [0.00] Kernel command line: root=/dev/sda2 ro quiet splash locale=es_ES [0.00] Initializing CPU#0 [
BUG?: "Cannot map mmconfig aperture"
I get the following new message in my dmesg: [0.155476] ACPI: bus type pci registered [0.155567] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support. [0.161149] PCI: Cannot map mmconfig aperture for segment 0 [0.161181] PCI: Using configuration type 1 [0.165980] ACPI: EC: Look up EC in DSDT when previously i'd have: [0.156577] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support. [0.166403] PCI: Using MMCONFIG at e000 - efff [0.166407] PCI: Using configuration type 1 [0.171548] ACPI: EC: Look up EC in DSDT No idea if this is a regression or not, or what it means, the system works well. git-bisect says the problem cames from: commit c31c7d4844ea4817692ae16bf70f9c96c05a50eb Author: Thomas Gleixner <[EMAIL PROTECTED]> Date: Mon Feb 18 20:54:14 2008 +0100 x86: CPA, fix alias checks -- 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/
BUG?: Cannot map mmconfig aperture
I get the following new message in my dmesg: [0.155476] ACPI: bus type pci registered [0.155567] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support. [0.161149] PCI: Cannot map mmconfig aperture for segment 0 [0.161181] PCI: Using configuration type 1 [0.165980] ACPI: EC: Look up EC in DSDT when previously i'd have: [0.156577] PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub with MMCONFIG support. [0.166403] PCI: Using MMCONFIG at e000 - efff [0.166407] PCI: Using configuration type 1 [0.171548] ACPI: EC: Look up EC in DSDT No idea if this is a regression or not, or what it means, the system works well. git-bisect says the problem cames from: commit c31c7d4844ea4817692ae16bf70f9c96c05a50eb Author: Thomas Gleixner [EMAIL PROTECTED] Date: Mon Feb 18 20:54:14 2008 +0100 x86: CPA, fix alias checks -- 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] [8/18] BKL-removal: Remove BKL from remote_llseek
El Mon, 28 Jan 2008 15:10:34 +0100, Andi Kleen <[EMAIL PROTECTED]> escribió: > So you get overlapping reads. Probably not good. This was discussed in the past i think -> http://lkml.org/lkml/2006/4/13/124 http://lkml.org/lkml/2006/4/13/130 -- 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] [8/18] BKL-removal: Remove BKL from remote_llseek
El Mon, 28 Jan 2008 15:10:34 +0100, Andi Kleen [EMAIL PROTECTED] escribió: So you get overlapping reads. Probably not good. This was discussed in the past i think - http://lkml.org/lkml/2006/4/13/124 http://lkml.org/lkml/2006/4/13/130 -- 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] ext3: per-process soft-syncing data=ordered mode
El Thu, 24 Jan 2008 23:36:00 +0300, Al Boldi <[EMAIL PROTECTED]> escribió:
> Greetings!
>
> data=ordered mode has proven reliable over the years, and it does this by
> ordering filedata flushes before metadata flushes. But this sometimes
> causes contention in the order of a 10x slowdown for certain apps, either
> due to the misuse of fsync or due to inherent behaviour like db's, as well
> as inherent starvation issues exposed by the data=ordered mode.
There's a related bug in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=9546
The diagnostic from Jan Kara is different though, but I think it may be the same
problem...
"One process does data-intensive load. Thus in the ordered mode the
transaction is tiny but has tons of data buffers attached. If commit
happens, it takes a long time to sync all the data before the commit
can proceed... In the writeback mode, we don't wait for data buffers, in
the journal mode amount of data to be written is really limited by the
maximum size of a transaction and so we write by much smaller chunks
and better latency is thus ensured."
I'm hitting this bug too...it's surprising that there's not many people
reporting more bugs about this, because it's really annoying.
There's a patch by Jan Kara (that I'm including here because bugzilla didn't
include it and took me a while to find it) which I don't know if it's supposed
to
fix the problem , but it'd be interesting to try:
Don't allow too much data buffers in a transaction.
diff --git a/fs/jbd/transaction.c b/fs/jbd/transaction.c
index 08ff6c7..e6f9dd6 100644
--- a/fs/jbd/transaction.c
+++ b/fs/jbd/transaction.c
@@ -163,7 +163,7 @@ repeat_locked:
spin_lock(>t_handle_lock);
needed = transaction->t_outstanding_credits + nblocks;
- if (needed > journal->j_max_transaction_buffers) {
+ if (needed > journal->j_max_transaction_buffers ||
atomic_read(>t_data_buf_count) > 32768) {
/*
* If the current transaction is already too large, then start
* to commit it: we can then go back and attach this handle to
@@ -1528,6 +1528,7 @@ static void __journal_temp_unlink_buffer(struct
journal_head *jh)
return;
case BJ_SyncData:
list = >t_sync_datalist;
+ atomic_dec(>t_data_buf_count);
break;
case BJ_Metadata:
transaction->t_nr_buffers--;
@@ -1989,6 +1990,7 @@ void __journal_file_buffer(struct journal_head *jh,
return;
case BJ_SyncData:
list = >t_sync_datalist;
+ atomic_inc(>t_data_buf_count);
break;
case BJ_Metadata:
transaction->t_nr_buffers++;
diff --git a/include/linux/jbd.h b/include/linux/jbd.h
index d9ecd13..6dd284a 100644
--- a/include/linux/jbd.h
+++ b/include/linux/jbd.h
@@ -541,6 +541,12 @@ struct transaction_s
int t_outstanding_credits;
/*
+* Number of data buffers on t_sync_datalist attached to
+* the transaction.
+*/
+ atomic_tt_data_buf_count;
+
+ /*
* Forward and backward links for the circular list of all transactions
* awaiting checkpoint. [j_list_lock]
*/
--
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] ext3: per-process soft-syncing data=ordered mode
El Thu, 24 Jan 2008 23:36:00 +0300, Al Boldi [EMAIL PROTECTED] escribió:
Greetings!
data=ordered mode has proven reliable over the years, and it does this by
ordering filedata flushes before metadata flushes. But this sometimes
causes contention in the order of a 10x slowdown for certain apps, either
due to the misuse of fsync or due to inherent behaviour like db's, as well
as inherent starvation issues exposed by the data=ordered mode.
There's a related bug in bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=9546
The diagnostic from Jan Kara is different though, but I think it may be the same
problem...
One process does data-intensive load. Thus in the ordered mode the
transaction is tiny but has tons of data buffers attached. If commit
happens, it takes a long time to sync all the data before the commit
can proceed... In the writeback mode, we don't wait for data buffers, in
the journal mode amount of data to be written is really limited by the
maximum size of a transaction and so we write by much smaller chunks
and better latency is thus ensured.
I'm hitting this bug too...it's surprising that there's not many people
reporting more bugs about this, because it's really annoying.
There's a patch by Jan Kara (that I'm including here because bugzilla didn't
include it and took me a while to find it) which I don't know if it's supposed
to
fix the problem , but it'd be interesting to try:
Don't allow too much data buffers in a transaction.
diff --git a/fs/jbd/transaction.c b/fs/jbd/transaction.c
index 08ff6c7..e6f9dd6 100644
--- a/fs/jbd/transaction.c
+++ b/fs/jbd/transaction.c
@@ -163,7 +163,7 @@ repeat_locked:
spin_lock(transaction-t_handle_lock);
needed = transaction-t_outstanding_credits + nblocks;
- if (needed journal-j_max_transaction_buffers) {
+ if (needed journal-j_max_transaction_buffers ||
atomic_read(transaction-t_data_buf_count) 32768) {
/*
* If the current transaction is already too large, then start
* to commit it: we can then go back and attach this handle to
@@ -1528,6 +1528,7 @@ static void __journal_temp_unlink_buffer(struct
journal_head *jh)
return;
case BJ_SyncData:
list = transaction-t_sync_datalist;
+ atomic_dec(transaction-t_data_buf_count);
break;
case BJ_Metadata:
transaction-t_nr_buffers--;
@@ -1989,6 +1990,7 @@ void __journal_file_buffer(struct journal_head *jh,
return;
case BJ_SyncData:
list = transaction-t_sync_datalist;
+ atomic_inc(transaction-t_data_buf_count);
break;
case BJ_Metadata:
transaction-t_nr_buffers++;
diff --git a/include/linux/jbd.h b/include/linux/jbd.h
index d9ecd13..6dd284a 100644
--- a/include/linux/jbd.h
+++ b/include/linux/jbd.h
@@ -541,6 +541,12 @@ struct transaction_s
int t_outstanding_credits;
/*
+* Number of data buffers on t_sync_datalist attached to
+* the transaction.
+*/
+ atomic_tt_data_buf_count;
+
+ /*
* Forward and backward links for the circular list of all transactions
* awaiting checkpoint. [j_list_lock]
*/
--
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: The ext3 way of journalling
http://freebsd.org http://netbsd.org http://openbsd.org http://opensolaris.org There're so many options, that wasting your time arguing with people that thinks that you're a troll is worthless. -- 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: The ext3 way of journalling
http://freebsd.org http://netbsd.org http://openbsd.org http://opensolaris.org There're so many options, that wasting your time arguing with people that thinks that you're a troll is worthless. -- 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 patch] let EXT4DEV_FS depend on BROKEN
El Wed, 2 Jan 2008 03:32:18 +0200, Adrian Bunk <[EMAIL PROTECTED]> escribió: > It might make sense to offer ext4 in -mm and even in early -rc kernels, > but I've already seen people using ext4 simply because a stable kernel > offered it - and that's definitely not intended. But isn't that the whole purpose of having ext4 snapshots in the stable kernel - to allow people to try it? -- 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 patch] let EXT4DEV_FS depend on BROKEN
El Wed, 2 Jan 2008 03:32:18 +0200, Adrian Bunk [EMAIL PROTECTED] escribió: It might make sense to offer ext4 in -mm and even in early -rc kernels, but I've already seen people using ext4 simply because a stable kernel offered it - and that's definitely not intended. But isn't that the whole purpose of having ext4 snapshots in the stable kernel - to allow people to try it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc4
As usually, if someone finds errors in http://kernelnewbies.org/Linux_2_6_24 , let me know it or change it yourself. -- 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: Kernel Development & Objective-C
El Tue, 4 Dec 2007 22:47:45 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> escribió: > That is what I like of C++, with good placement of high level features > like const's and & (references) one can gain fine control over what > gets copied or not. But...if there's some way Linux can get "language improvements", is with new C standards/gccextensions/etc. It'd be nice if people tried to add (useful) C extensions to gcc, instead of proposing some random language :) -- 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: Kernel Development Objective-C
El Tue, 4 Dec 2007 22:47:45 +0100, J.A. Magallón [EMAIL PROTECTED] escribió: That is what I like of C++, with good placement of high level features like const's and (references) one can gain fine control over what gets copied or not. But...if there's some way Linux can get language improvements, is with new C standards/gccextensions/etc. It'd be nice if people tried to add (useful) C extensions to gcc, instead of proposing some random language :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc4
As usually, if someone finds errors in http://kernelnewbies.org/Linux_2_6_24 , let me know it or change it yourself. -- 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: Is it possible to give the user the option to cancel forkbombs?
El Sat, 17 Nov 2007 09:42:51 -0800, Martin Olsson <[EMAIL PROTECTED]> escribió: > I don't think that setting a max process count by default is a > good/viable solution. I don't see why...OS X had a default limit of 100 processes per uid (increased to 266 in 10.5) and "it works" (many people notices it, but it's not surprising since the limit is too restrictive). If you don't have limits, you can't avoid starvation easily. From my experience, since I use CFS, fork/compile bombs (forgetting to put a number after make -j...) are very sluggish mainly because the whole graphic subsystem is paged out. - 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: Is it possible to give the user the option to cancel forkbombs?
El Sat, 17 Nov 2007 09:42:51 -0800, Martin Olsson [EMAIL PROTECTED] escribió: I don't think that setting a max process count by default is a good/viable solution. I don't see why...OS X had a default limit of 100 processes per uid (increased to 266 in 10.5) and it works (many people notices it, but it's not surprising since the limit is too restrictive). If you don't have limits, you can't avoid starvation easily. From my experience, since I use CFS, fork/compile bombs (forgetting to put a number after make -j...) are very sluggish mainly because the whole graphic subsystem is paged out. - 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: Is it possible to give the user the option to cancel forkbombs?
El Fri, 16 Nov 2007 21:51:27 -0800, Martin Olsson <[EMAIL PROTECTED]> escribió: > Dear kernel hackers, > > This is a message from below 0x7FFF. Please look at this bug (it's > not a new concept but still): > https://bugs.launchpad.net/ubuntu/+bug/163185 Can't see that page: -- Not allowed here Sorry, you don't have permission to access this page. > CTRL-ALT-DEL to work. Maybe it's possible to set some kind of > MAX_PROCESS_COUNT for each user (I don't know) but it looks like this is > not done by default in many distros today? Per-user process limits have been there for a long time, most of distros don't use them and don't offer GUIs to configure them. - 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: Is it possible to give the user the option to cancel forkbombs?
El Fri, 16 Nov 2007 21:51:27 -0800, Martin Olsson [EMAIL PROTECTED] escribió: Dear kernel hackers, This is a message from below 0x7FFF. Please look at this bug (it's not a new concept but still): https://bugs.launchpad.net/ubuntu/+bug/163185 Can't see that page: -- Not allowed here Sorry, you don't have permission to access this page. CTRL-ALT-DEL to work. Maybe it's possible to set some kind of MAX_PROCESS_COUNT for each user (I don't know) but it looks like this is not done by default in many distros today? Per-user process limits have been there for a long time, most of distros don't use them and don't offer GUIs to configure them. - 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] Improve cgroup printks
When I boot with the 'quiet' parameter, I see on the screen:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[ 39.036026] Initializing cgroup subsys cpuacct
[ 39.036080] Initializing cgroup subsys debug
[ 39.036118] Initializing cgroup subsys ns
This patch lowers the priority of those messages, adds a "cgroup: " prefix
to another couple of printks and kills the useless reference to the source file.
Signed-off-by: Diego Calleja <[EMAIL PROTECTED]>
--- 2.6/kernel/cgroup.c.old 2007-11-10 11:35:51.0 +0100
+++ 2.6/kernel/cgroup.c 2007-11-10 11:56:46.0 +0100
@@ -1,6 +1,4 @@
/*
- * kernel/cgroup.c
- *
* Generic process-grouping system.
*
* Based originally on the cpuset system, extracted by Paul Menage
@@ -2200,7 +2198,7 @@ static void cgroup_init_subsys(struct cg
{
struct cgroup_subsys_state *css;
struct list_head *l;
- printk(KERN_ERR "Initializing cgroup subsys %s\n", ss->name);
+ printk("Initializing cgroup subsys %s\n", ss->name);
/* Create the top cgroup state for this subsystem */
ss->root =
@@ -2273,7 +2271,7 @@ int __init cgroup_init_early(void)
BUG_ON(!ss->create);
BUG_ON(!ss->destroy);
if (ss->subsys_id != i) {
- printk(KERN_ERR "Subsys %s id == %d\n",
+ printk(KERN_ERR "cgroup: Subsys %s id == %d\n",
ss->name, ss->subsys_id);
BUG();
}
@@ -2605,7 +2603,7 @@ int cgroup_clone(struct task_struct *tsk
dentry = lookup_one_len(nodename, parent->dentry, strlen(nodename));
if (IS_ERR(dentry)) {
printk(KERN_INFO
- "Couldn't allocate dentry for %s: %ld\n", nodename,
+ "cgroup: Couldn't allocate dentry for %s: %ld\n",
nodename,
PTR_ERR(dentry));
ret = PTR_ERR(dentry);
goto out_release;
-
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] Improve cgroup printks
When I boot with the 'quiet' parameter, I see on the screen:
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[ 39.036026] Initializing cgroup subsys cpuacct
[ 39.036080] Initializing cgroup subsys debug
[ 39.036118] Initializing cgroup subsys ns
This patch lowers the priority of those messages, adds a cgroup: prefix
to another couple of printks and kills the useless reference to the source file.
Signed-off-by: Diego Calleja [EMAIL PROTECTED]
--- 2.6/kernel/cgroup.c.old 2007-11-10 11:35:51.0 +0100
+++ 2.6/kernel/cgroup.c 2007-11-10 11:56:46.0 +0100
@@ -1,6 +1,4 @@
/*
- * kernel/cgroup.c
- *
* Generic process-grouping system.
*
* Based originally on the cpuset system, extracted by Paul Menage
@@ -2200,7 +2198,7 @@ static void cgroup_init_subsys(struct cg
{
struct cgroup_subsys_state *css;
struct list_head *l;
- printk(KERN_ERR Initializing cgroup subsys %s\n, ss-name);
+ printk(Initializing cgroup subsys %s\n, ss-name);
/* Create the top cgroup state for this subsystem */
ss-root = rootnode;
@@ -2273,7 +2271,7 @@ int __init cgroup_init_early(void)
BUG_ON(!ss-create);
BUG_ON(!ss-destroy);
if (ss-subsys_id != i) {
- printk(KERN_ERR Subsys %s id == %d\n,
+ printk(KERN_ERR cgroup: Subsys %s id == %d\n,
ss-name, ss-subsys_id);
BUG();
}
@@ -2605,7 +2603,7 @@ int cgroup_clone(struct task_struct *tsk
dentry = lookup_one_len(nodename, parent-dentry, strlen(nodename));
if (IS_ERR(dentry)) {
printk(KERN_INFO
- Couldn't allocate dentry for %s: %ld\n, nodename,
+ cgroup: Couldn't allocate dentry for %s: %ld\n,
nodename,
PTR_ERR(dentry));
ret = PTR_ERR(dentry);
goto out_release;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
El Tue, 2 Oct 2007 16:32:00 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > Heh. The "remove sk98lin driver" bullet is sadly wrong. We had to > reinstate it because it supported some cards that the skge driver doesn't > handle. Thanks, fixed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
El Tue, 2 Oct 2007 16:32:00 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: Heh. The remove sk98lin driver bullet is sadly wrong. We had to reinstate it because it supported some cards that the skge driver doesn't handle. Thanks, fixed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
El Mon, 1 Oct 2007 20:41:49 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > So there's a final -rc out there, and right now my plan is to make this > series really short, and release 2.6.23 in a few days. So please do give > it a last good testing, and holler about any issues you find! Also...if someone dislikes something in http://kernelnewbies.org/Linux_2_6_23 , or wants to fix my english, do it soon :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
El Mon, 1 Oct 2007 20:41:49 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: So there's a final -rc out there, and right now my plan is to make this series really short, and release 2.6.23 in a few days. So please do give it a last good testing, and holler about any issues you find! Also...if someone dislikes something in http://kernelnewbies.org/Linux_2_6_23 , or wants to fix my english, do it soon :) - 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: Coding FATX support for 2.6
El Sun, 23 Sep 2007 16:51:15 -0400, Hector Martin <[EMAIL PROTECTED]> escribió: > Most xbox-linux users are stuck using 2.4, since there is no FATX driver > for 2.6 and the 2.4 one is unmaintained. I've been thinking about > writing FATX support into 2.6, to finally end this problem (this is > basically the only thing holding up 2.6 for Xbox Linux distros). While I > have done a little kernel coding in the past, I've never messed with > filesystems in Linux and I'm not entirely sure what the best approach > would be here. I would like to do it in such a way that it can be FUSE could be an acceptable solution. - 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/
Urgent bugzilla mainteinance needed
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
bugzilla tries to send a mail to the reporter, it fails ("unknown user
account"),
but the error failure is appended as a bugzilla comment. Then bugzilla tries to
send that comment to everyone involved in the bug, including the reporter,
so it fails again.Houston, we've a endless loop.
There're 540 comments in that bug report already, and the bugme-daemon
mail list is being spammed
-
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/
Urgent bugzilla mainteinance needed
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710 bugzilla tries to send a mail to the reporter, it fails (unknown user account), but the error failure is appended as a bugzilla comment. Then bugzilla tries to send that comment to everyone involved in the bug, including the reporter, so it fails again.Houston, we've a endless loop. There're 540 comments in that bug report already, and the bugme-daemon mail list is being spammed - 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: Coding FATX support for 2.6
El Sun, 23 Sep 2007 16:51:15 -0400, Hector Martin [EMAIL PROTECTED] escribió: Most xbox-linux users are stuck using 2.4, since there is no FATX driver for 2.6 and the 2.4 one is unmaintained. I've been thinking about writing FATX support into 2.6, to finally end this problem (this is basically the only thing holding up 2.6 for Xbox Linux distros). While I have done a little kernel coding in the past, I've never messed with filesystems in Linux and I'm not entirely sure what the best approach would be here. I would like to do it in such a way that it can be FUSE could be an acceptable solution. - 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 00/23] per device dirty throttling -v8
El Thu, 09 Aug 2007 11:02:38 -0400, Chuck Ebbert <[EMAIL PROTECTED]> escribió: > NT maintains atimes by default, at least up to XP. You have to edit the > registry to turn them off, and it is a single global switch -- not per > mountpoint like Unix. > > And it makes a huge difference there, too. In windows Vista they've disabled atime updates by default. And XP maintains atimes, but it uses a trick to avoid the performance penalty we suffer in linux, similar to what Andi Kleen suggested: they keep atime updates in memory for one hour, and only sync to disk after that time - of course they also sync it if there's a oportunity to do it, like when updating mtime. - 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 00/23] per device dirty throttling -v8
El Thu, 09 Aug 2007 11:02:38 -0400, Chuck Ebbert [EMAIL PROTECTED] escribió: NT maintains atimes by default, at least up to XP. You have to edit the registry to turn them off, and it is a single global switch -- not per mountpoint like Unix. And it makes a huge difference there, too. In windows Vista they've disabled atime updates by default. And XP maintains atimes, but it uses a trick to avoid the performance penalty we suffer in linux, similar to what Andi Kleen suggested: they keep atime updates in memory for one hour, and only sync to disk after that time - of course they also sync it if there's a oportunity to do it, like when updating mtime. - 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 00/23] per device dirty throttling -v8
El Sun, 5 Aug 2007 09:13:20 +0200, Ingo Molnar <[EMAIL PROTECTED]> escribió: > Measurements show that noatime helps 20-30% on regular desktop > workloads, easily 50% for kernel builds and much more than that (in > excess of 100%) for file-read-intense workloads. We cannot just walk And as everybody knows in servers is a popular practice to disable it. According to an interview to the kernel.org admins "Beyond that, Peter noted, "very little fancy is going on, and that is good because fancy is hard to maintain." He explained that the only fancy thing being done is that all filesystems are mounted noatime meaning that the system doesn't have to make writes to the filesystem for files which are simply being read, "that cut the load average in half." I bet that some people would consider such performance hit a bug... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/23] per device dirty throttling -v8
El Sun, 5 Aug 2007 09:13:20 +0200, Ingo Molnar [EMAIL PROTECTED] escribió: Measurements show that noatime helps 20-30% on regular desktop workloads, easily 50% for kernel builds and much more than that (in excess of 100%) for file-read-intense workloads. We cannot just walk And as everybody knows in servers is a popular practice to disable it. According to an interview to the kernel.org admins Beyond that, Peter noted, very little fancy is going on, and that is good because fancy is hard to maintain. He explained that the only fancy thing being done is that all filesystems are mounted noatime meaning that the system doesn't have to make writes to the filesystem for files which are simply being read, that cut the load average in half. I bet that some people would consider such performance hit a bug... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/23] per device dirty throttling -v8
El Sat, 4 Aug 2007 19:38:01 +0200, Diego Calleja <[EMAIL PROTECTED]> escribió: > Mmmh, "mount -o remount,noatime /" seems to Work For Me in Ubuntu > with util-linux/mount "2.12r-17ubuntu"...but then Google says [1] that > Ubuntu has been shipping with relatime enabled as default for months, ^ Obviously, i meant "noatime"...(so it's unlikely that ubuntu has patched anything to support relatime - it's not reflected in the changelogs at least) > so it's probably patched (probably only in the kernel). So maybe upstream > util-linux hasn't merged the relatime patch. > > [1]: http://lkml.org/lkml/2007/2/12/30 - 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 00/23] per device dirty throttling -v8
El Sat, 4 Aug 2007 19:17:24 +0200, Ingo Molnar <[EMAIL PROTECTED]> escribió: > i've got util-linux-2.13-0.46.fc6 and 2.6.22 on that box, shouldnt that > be recent enough? As far as i can see it from the kernel-side code, this > works on the general VFS level and hence should be supported by ext3 > already. Mmmh, "mount -o remount,noatime /" seems to Work For Me in Ubuntu with util-linux/mount "2.12r-17ubuntu"...but then Google says [1] that Ubuntu has been shipping with relatime enabled as default for months, so it's probably patched (probably only in the kernel). So maybe upstream util-linux hasn't merged the relatime patch. [1]: http://lkml.org/lkml/2007/2/12/30 - 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 00/23] per device dirty throttling -v8
El Sat, 4 Aug 2007 18:37:33 +0200, Ingo Molnar <[EMAIL PROTECTED]> escribió: > thousands of applications. So for most file workloads we give Windows a > 20%-30% performance edge, for almost nothing. (for RAM-starved kernel > builds the performance difference between atime and noatime+nodiratime > setups is more on the order of 40%) Just curious - do you have numbers with relatime? - 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 00/23] per device dirty throttling -v8
El Sat, 4 Aug 2007 18:37:33 +0200, Ingo Molnar [EMAIL PROTECTED] escribió: thousands of applications. So for most file workloads we give Windows a 20%-30% performance edge, for almost nothing. (for RAM-starved kernel builds the performance difference between atime and noatime+nodiratime setups is more on the order of 40%) Just curious - do you have numbers with relatime? - 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 00/23] per device dirty throttling -v8
El Sat, 4 Aug 2007 19:17:24 +0200, Ingo Molnar [EMAIL PROTECTED] escribió: i've got util-linux-2.13-0.46.fc6 and 2.6.22 on that box, shouldnt that be recent enough? As far as i can see it from the kernel-side code, this works on the general VFS level and hence should be supported by ext3 already. Mmmh, mount -o remount,noatime / seems to Work For Me in Ubuntu with util-linux/mount 2.12r-17ubuntu...but then Google says [1] that Ubuntu has been shipping with relatime enabled as default for months, so it's probably patched (probably only in the kernel). So maybe upstream util-linux hasn't merged the relatime patch. [1]: http://lkml.org/lkml/2007/2/12/30 - 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 00/23] per device dirty throttling -v8
El Sat, 4 Aug 2007 19:38:01 +0200, Diego Calleja [EMAIL PROTECTED] escribió: Mmmh, mount -o remount,noatime / seems to Work For Me in Ubuntu with util-linux/mount 2.12r-17ubuntu...but then Google says [1] that Ubuntu has been shipping with relatime enabled as default for months, ^ Obviously, i meant noatime...(so it's unlikely that ubuntu has patched anything to support relatime - it's not reflected in the changelogs at least) so it's probably patched (probably only in the kernel). So maybe upstream util-linux hasn't merged the relatime patch. [1]: http://lkml.org/lkml/2007/2/12/30 - 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: inotify and /proc/
El Mon, 30 Jul 2007 22:25:21 -0500, Joseph Pingenot <[EMAIL PROTECTED]> escribió: > More background, please? > > What's the way to check for a process exiting without spinning? I don't know if it's useful for you, but CONFIG_CONNECTOR and CONFIG_PROC_EVENTS will report process creation/exit/fork/etc through a netlink interface. - 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: inotify and /proc/pid
El Mon, 30 Jul 2007 22:25:21 -0500, Joseph Pingenot [EMAIL PROTECTED] escribió: More background, please? What's the way to check for a process exiting without spinning? I don't know if it's useful for you, but CONFIG_CONNECTOR and CONFIG_PROC_EVENTS will report process creation/exit/fork/etc through a netlink interface. - 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: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> escribió: > The scheduler could have and still can undertake good solid transformation, > but getting folks to listen is another story which is why Con quit. CFS > basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. > This time it was Con being the Mindcraft catalyst. But he's on *our* side > and he got beat down by the Linux kernel community. That's the tragedy here. > He was beaten down by the very people he was trying to help out and > support. It should have been handled better. Get real: I don't the linux development has always been "friendly". The idea of a "GNU-hippie community" where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. - 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: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) [EMAIL PROTECTED] escribió: The scheduler could have and still can undertake good solid transformation, but getting folks to listen is another story which is why Con quit. CFS basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. This time it was Con being the Mindcraft catalyst. But he's on *our* side and he got beat down by the Linux kernel community. That's the tragedy here. He was beaten down by the very people he was trying to help out and support. It should have been handled better. Get real: I don't the linux development has always been friendly. The idea of a GNU-hippie community where everybody is good and helps others and shares their pots is what the Sun bloggers seem to think that opensolaris should resemble, but it doesn't matches the real world. - 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: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) <[EMAIL PROTECTED]> escribió: > of how crappy X is. This is an open argument on how to solve, but it > should not have resulted in really one scheduler over the other. Both So your argument is that SD shouldn't have been merged either, because it would have resulted in one scheduler over the other? > where capable but one is locked out now because of the choices of > current high level kernel developers in Linux. Well, there are two schedulers...it's obvious that "high level kernel developers" needed to chose one. The main problem is clearly that no scheduler was clearly better than the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both of them were good enought, but only one of them could be merged. The difference is that EVMS developers didn't get that annoyed, and not only they didn't quit but they continued developing their userspace tools to make it work with the solution included in the kernel (http://lwn.net/Articles/14714/) - 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: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > So "modal" things are good for fixing behaviour in the short run. But they > are a total disaster in the long run, and even in the short run they tend > to have problems (simply because there will be cases that straddle the > line, and show some of _both_ issues, and now *neither* mode is the right > one) I fully agree with this, but plugsched could have avoided this useless "division" on the topic of SD vs CFS. IMO that counts as an advantage, too ;) - 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: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: So modal things are good for fixing behaviour in the short run. But they are a total disaster in the long run, and even in the short run they tend to have problems (simply because there will be cases that straddle the line, and show some of _both_ issues, and now *neither* mode is the right one) I fully agree with this, but plugsched could have avoided this useless division on the topic of SD vs CFS. IMO that counts as an advantage, too ;) - 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: [ck] Re: Linus 2.6.23-rc1
El Sat, 28 Jul 2007 13:07:05 -0700, Bill Huey (hui) [EMAIL PROTECTED] escribió: of how crappy X is. This is an open argument on how to solve, but it should not have resulted in really one scheduler over the other. Both So your argument is that SD shouldn't have been merged either, because it would have resulted in one scheduler over the other? where capable but one is locked out now because of the choices of current high level kernel developers in Linux. Well, there are two schedulers...it's obvious that high level kernel developers needed to chose one. The main problem is clearly that no scheduler was clearly better than the other. This remembers me of the LVM2/MD vs EVMS in the 2.5 days - both of them were good enought, but only one of them could be merged. The difference is that EVMS developers didn't get that annoyed, and not only they didn't quit but they continued developing their userspace tools to make it work with the solution included in the kernel (http://lwn.net/Articles/14714/) - 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: How innovative is Linux?
El Sat, 23 Jun 2007 23:00:42 +0530, jimmy bahuleyan <[EMAIL PROTECTED]> escribió: > building upon or improving existing technology is as important as > inventing new things. if every one insisted on dreaming up new things, i > doubt we would've accomplished anything significant (not just in OS, > anywhere ;) Let's also not forget that many of the "innovative" features that Grodzan says Linux has copied to Solaris and other Unixes, were actually not invented by them. OS/2 already had dtrace in 1994 (it even had the same name), and many of the traditional Unix features were copied^Wheavily inspired in multics. - 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: How innovative is Linux?
El Sat, 23 Jun 2007 23:00:42 +0530, jimmy bahuleyan [EMAIL PROTECTED] escribió: building upon or improving existing technology is as important as inventing new things. if every one insisted on dreaming up new things, i doubt we would've accomplished anything significant (not just in OS, anywhere ;) Let's also not forget that many of the innovative features that Grodzan says Linux has copied to Solaris and other Unixes, were actually not invented by them. OS/2 already had dtrace in 1994 (it even had the same name), and many of the traditional Unix features were copied^Wheavily inspired in multics. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
El Tue, 19 Jun 2007 20:21:53 +0200, Nicolas Mailhot <[EMAIL PROTECTED]> escribió: > traffic regulations only consider cars? I think not. Yet the same > argument is the core of most GPL v3 objections we've seen in this > thread. No, the core argument of the GPLv3 objections is that you can NOT tell the hardware manufacturers how to build hardware. You only can tell software users what hardware (tivoized) it's forbidden for them. Wether or not the hardware manufacturers are going to care enought about your anti-tivo software to remove their tivo protections is a completely different question unrelated to the software license. Which is why the GPLv3 anti-tivoization measures are stupid and pointless. Please, stop pretending you are hardware manufacturers. You are not. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
El Tue, 19 Jun 2007 20:21:53 +0200, Nicolas Mailhot [EMAIL PROTECTED] escribió: traffic regulations only consider cars? I think not. Yet the same argument is the core of most GPL v3 objections we've seen in this thread. No, the core argument of the GPLv3 objections is that you can NOT tell the hardware manufacturers how to build hardware. You only can tell software users what hardware (tivoized) it's forbidden for them. Wether or not the hardware manufacturers are going to care enought about your anti-tivo software to remove their tivo protections is a completely different question unrelated to the software license. Which is why the GPLv3 anti-tivoization measures are stupid and pointless. Please, stop pretending you are hardware manufacturers. You are not. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
El Thu, 14 Jun 2007 16:55:09 -0300, Alexandre Oliva <[EMAIL PROTECTED]> escribió: > > On Thu, 14 Jun 2007, Diego Calleja wrote: > > >> And the FSF is trying to control the design and licensing of > >> hardware throught the influence of their software. > > It's not. It's only working to ensure recipients of the Free Software > can modify and share the software. Those may be the intentions, but I claim that your statement is false. The anti-tivoisation FSF movement is not "working to ensure recipients of the Free Software can modify and share the software". They can't, because the fact is that hardware vendors can NOT stop you from "modifing and sharing the software". They only can stop you from running your modifications, which is very different. So this is a _hardware_ limitation. It's pointless to try to address this problem with software licenses. What the anti-tivoisation movement is trying to do: "If you are a vendor of tivoized hardware you must give your users whatever information is needed to run modifications of their software" How it works in the real world: "You can't run this software in hardware that doesn't allow to run code modifications of this software" So while the anti-tivoisation movement is trying to limit hardware design/licensing, the fact is that what you are restricting is not the hardware, but the _software_, in a way very different from the 'restrictions' that the GPL has when compared with the BSD ie: in a way that doesn't benefit freedom or contribution of code. Because your users already can modify and share their code regardless of what hardware they're using (even if they can't run their modifications), you're just adding pointless prohibitions. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
El Thu, 14 Jun 2007 16:55:09 -0300, Alexandre Oliva [EMAIL PROTECTED] escribió: On Thu, 14 Jun 2007, Diego Calleja wrote: And the FSF is trying to control the design and licensing of hardware throught the influence of their software. It's not. It's only working to ensure recipients of the Free Software can modify and share the software. Those may be the intentions, but I claim that your statement is false. The anti-tivoisation FSF movement is not working to ensure recipients of the Free Software can modify and share the software. They can't, because the fact is that hardware vendors can NOT stop you from modifing and sharing the software. They only can stop you from running your modifications, which is very different. So this is a _hardware_ limitation. It's pointless to try to address this problem with software licenses. What the anti-tivoisation movement is trying to do: If you are a vendor of tivoized hardware you must give your users whatever information is needed to run modifications of their software How it works in the real world: You can't run this software in hardware that doesn't allow to run code modifications of this software So while the anti-tivoisation movement is trying to limit hardware design/licensing, the fact is that what you are restricting is not the hardware, but the _software_, in a way very different from the 'restrictions' that the GPL has when compared with the BSD ie: in a way that doesn't benefit freedom or contribution of code. Because your users already can modify and share their code regardless of what hardware they're using (even if they can't run their modifications), you're just adding pointless prohibitions. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
El Thu, 14 Jun 2007 14:49:19 -0300, Alexandre Oliva <[EMAIL PROTECTED]> escribió: > Let me see if I got your position right: when TiVO imposes > restrictions, that's ok, but when others want to find ways to stop it, > then it's not. *Now* I'm confused ;-) Me, I agree that hardware shouldn't lock users. And since I'm one of those evil european socialdemocrats, I may go as far as to think that there should be laws that *forbid* selling such hardware. But I think that all this iss a *hardware* issue. It seems to me that lot of people at the FSF wants to regulate the hardware industry using the influence of free/open software in the computing industry and the "V2 or later" phrase from the GPL. But the fact is that free/open source runs on _top_ of hardware. You don't control hardware, you only control the things that are built on top of your software, not the parts you use to build your software. And the FSF is trying to control the design and licensing of hardware throught the influence of their software. And I think it's wrong. I'm all to forbid hardware that imposes restrictions on hardware, but software licenses are NOT the way to make it. That's a task for a "Free Hardware Foundation", not the FSF. What the FSF is trying to do is EVIL. It's not about free software, it's not about freedom, it's about the FSF trying to have to much control over things that they shouldn't even try to control. I think that the FSF can do a terrible damage to free/open source with such stupid ideas. I wouldn't even be surprised that some jugde rules that a software license that tries to 'control' hardware is invalid - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
El Thu, 14 Jun 2007 14:49:19 -0300, Alexandre Oliva [EMAIL PROTECTED] escribió: Let me see if I got your position right: when TiVO imposes restrictions, that's ok, but when others want to find ways to stop it, then it's not. *Now* I'm confused ;-) Me, I agree that hardware shouldn't lock users. And since I'm one of those evil european socialdemocrats, I may go as far as to think that there should be laws that *forbid* selling such hardware. But I think that all this iss a *hardware* issue. It seems to me that lot of people at the FSF wants to regulate the hardware industry using the influence of free/open software in the computing industry and the V2 or later phrase from the GPL. But the fact is that free/open source runs on _top_ of hardware. You don't control hardware, you only control the things that are built on top of your software, not the parts you use to build your software. And the FSF is trying to control the design and licensing of hardware throught the influence of their software. And I think it's wrong. I'm all to forbid hardware that imposes restrictions on hardware, but software licenses are NOT the way to make it. That's a task for a Free Hardware Foundation, not the FSF. What the FSF is trying to do is EVIL. It's not about free software, it's not about freedom, it's about the FSF trying to have to much control over things that they shouldn't even try to control. I think that the FSF can do a terrible damage to free/open source with such stupid ideas. I wouldn't even be surprised that some jugde rules that a software license that tries to 'control' hardware is invalid - 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: kconfig .po files in kernel tree? [Was: Documentation/HOWTO translated into Japanese]
El Sun, 10 Jun 2007 19:52:28 +0200, Sam Ravnborg <[EMAIL PROTECTED]> escribió: > I advocated that they should stay out back then. > But on the other hand I do not see it causing much troubles > having scripts/kconfig/po/da.po etc araound. > > Any opinion about the .po files? These days the configuration menus are not something that users need to read, they're more like a developer tool. IMO there's not much value in it, because the people who read it already know english most of the times. - 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: kconfig .po files in kernel tree? [Was: Documentation/HOWTO translated into Japanese]
El Sun, 10 Jun 2007 19:52:28 +0200, Sam Ravnborg [EMAIL PROTECTED] escribió: I advocated that they should stay out back then. But on the other hand I do not see it causing much troubles having scripts/kconfig/po/da.po etc araound. Any opinion about the .po files? These days the configuration menus are not something that users need to read, they're more like a developer tool. IMO there's not much value in it, because the people who read it already know english most of the times. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
El Thu, 24 May 2007 16:01:33 +0200 (CEST), Jiri Slaby <[EMAIL PROTECTED]> escribió: > +config USB_STK11XX > + tristate "STK11XX based webcams" > + depends on VIDEO_V4L2 > + ---help--- > + This will add support for Syntek webcams such as dc1125 and stk1135. > + > + If you choose to build it as module, it will be called stk11xx. Maybe this is a too picky requeriment, but IMO it would be nice if the module would be called "camera_stk11xx", or had any other prefix that gives some meaning about what is doing. It's hard to decipher from the name when you run lsmod. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH - 1/1] Documentation/HOWTO
El Thu, 24 May 2007 17:45:04 +0800, "Qi Yong" <[EMAIL PROTECTED]> escribió: > Hello, > > This duplicated paragraph problem was introduced by the following two > commits. They are one patch actually. D'oh, it seems the patch was picked from the mailing list and merged twice, and I didn't notice it. > Torvalds, Care to revert one commit? Agreed, one of them can be removed. > commit 722385f75efd82d9f480f0765a1e97a4d83cac0d > Author: Diego Calleja <[EMAIL PROTECTED]> > Date: Thu Sep 21 22:37:10 2006 +0200 > > HOWTO: bug report addition > > I suspect that not many people is subscribed to the bugzilla mailing list, > not surprising since the URLs doesn't seem to be in the tree :) > > After fixing my english, I wonder if the following patch could be > applied... > > Signed-off-by: Diego Calleja <[EMAIL PROTECTED]> > Acked-by: Randy Dunlap <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > commit 3f27100872b21e4cc70d07b96eeb3611b30bce63 > Author: Diego Calleja <[EMAIL PROTECTED]> > Date: Sat Sep 30 23:27:49 2006 -0700 > > [PATCH] HOWTO: mention bughunting > > Signed-off-by: Diego Calleja <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[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/
Re: [PATCH - 1/1] Documentation/HOWTO
El Thu, 24 May 2007 17:45:04 +0800, Qi Yong [EMAIL PROTECTED] escribió: Hello, This duplicated paragraph problem was introduced by the following two commits. They are one patch actually. D'oh, it seems the patch was picked from the mailing list and merged twice, and I didn't notice it. Torvalds, Care to revert one commit? Agreed, one of them can be removed. commit 722385f75efd82d9f480f0765a1e97a4d83cac0d Author: Diego Calleja [EMAIL PROTECTED] Date: Thu Sep 21 22:37:10 2006 +0200 HOWTO: bug report addition I suspect that not many people is subscribed to the bugzilla mailing list, not surprising since the URLs doesn't seem to be in the tree :) After fixing my english, I wonder if the following patch could be applied... Signed-off-by: Diego Calleja [EMAIL PROTECTED] Acked-by: Randy Dunlap [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] commit 3f27100872b21e4cc70d07b96eeb3611b30bce63 Author: Diego Calleja [EMAIL PROTECTED] Date: Sat Sep 30 23:27:49 2006 -0700 [PATCH] HOWTO: mention bughunting Signed-off-by: Diego Calleja [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [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/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
El Thu, 24 May 2007 16:01:33 +0200 (CEST), Jiri Slaby [EMAIL PROTECTED] escribió: +config USB_STK11XX + tristate STK11XX based webcams + depends on VIDEO_V4L2 + ---help--- + This will add support for Syntek webcams such as dc1125 and stk1135. + + If you choose to build it as module, it will be called stk11xx. Maybe this is a too picky requeriment, but IMO it would be nice if the module would be called camera_stk11xx, or had any other prefix that gives some meaning about what is doing. It's hard to decipher from the name when you run lsmod. - 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: Google are using linux kernel - what do you know about the source?
El Wed, 23 May 2007 16:23:44 +0200, Gergo Szakal <[EMAIL PROTECTED]> escribió: > Greetings to all list-members! > > Recently I have read that Google are selling enterprise hardware that > is running a modified version of the Linuk kernel [1]. I decided to ask > them whether the source is available. I did this via the question form > they offered. http://code.google.com/mirror/gsa.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: Google are using linux kernel - what do you know about the source?
El Wed, 23 May 2007 16:23:44 +0200, Gergo Szakal [EMAIL PROTECTED] escribió: Greetings to all list-members! Recently I have read that Google are selling enterprise hardware that is running a modified version of the Linuk kernel [1]. I decided to ask them whether the source is available. I did this via the question form they offered. http://code.google.com/mirror/gsa.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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
El Sat, 19 May 2007 16:02:37 -0400, Bill Davidsen <[EMAIL PROTECTED]> escribió: > The chart is at http://www.tmr.com/~davidsen/sched_smooth_01.html for > your viewing pleasure. The only "tuned" result was with sd, since what I > observed was so bad using the default settings. If any scheduler > developers would like me to try other tunings or new versions let me know. How useful is glxgears as benchmark here? The X.org people has been saying for ages that "glxgears is not a benchmark". Some people (at least on ubuntu) even patched it so that if you want to get FPS numbers, you need to pass the "-iacknowledgethatthistoolisnotabenchmark" option. There's a good page explaining why at http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark I realize that it may be OK for scheduler testing, but maybe it'd be more interesting to test other kind of 3d benchmark tools. - 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: Sched - graphic smoothness under load - cfs-v13 sd-0.48
El Sat, 19 May 2007 16:02:37 -0400, Bill Davidsen [EMAIL PROTECTED] escribió: The chart is at http://www.tmr.com/~davidsen/sched_smooth_01.html for your viewing pleasure. The only tuned result was with sd, since what I observed was so bad using the default settings. If any scheduler developers would like me to try other tunings or new versions let me know. How useful is glxgears as benchmark here? The X.org people has been saying for ages that glxgears is not a benchmark. Some people (at least on ubuntu) even patched it so that if you want to get FPS numbers, you need to pass the -iacknowledgethatthistoolisnotabenchmark option. There's a good page explaining why at http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark I realize that it may be OK for scheduler testing, but maybe it'd be more interesting to test other kind of 3d benchmark tools. - 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: FEATURE REQUEST: merge MD software raid and LVM in one unique layer.
El Wed, 2 May 2007 20:18:55 +0100, "Miguel Sousa Filipe" <[EMAIL PROTECTED]> escribió: > I find it high irritanting having two kernel interfaces and two > userland tools that provide the same funcionality, which one should I > use? I doubt users care about kernel's design; however the lack of unification of userspace tools is a real problem. Just my 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/
Re: FEATURE REQUEST: merge MD software raid and LVM in one unique layer.
El Wed, 2 May 2007 20:18:55 +0100, Miguel Sousa Filipe [EMAIL PROTECTED] escribió: I find it high irritanting having two kernel interfaces and two userland tools that provide the same funcionality, which one should I use? I doubt users care about kernel's design; however the lack of unification of userspace tools is a real problem. Just my 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/
Re: Linux 2.6.21
El Sun, 29 Apr 2007 23:10:28 +0200, Adrian Bunk <[EMAIL PROTECTED]> escribió: > What exactly is the purpose of the 2.6.21 regressions list in the Wiki? AFAIK, submitting its contents to the list periodically CCing the developers, like you did with your lists. If developers care to fix it or not or how much Linus cares about that list before releasing a new version is another question. I think it's useful because it makes those bugs look more important than the 1600 stored in the bugzilla...it won't help to fix those 1600, but it attracts some attention over the "release critical" ones and encourages developers to fix them, even if not all of them get fixed. I don't think you can do many other things to get as much bugs fixed as possible, unless we reward bug fixers with weekends in the Playboy mansion. I think the fundamental question here is: is there a way to make hackers follow and fix _all_ the bugs? I'd love it was possible, but AFAIK all the projects that have tried to be ultra-stable and have adopted a policy to fullfill such goal have fallen behind of competing projects that cared more about working in improving their software. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Sun, 29 Apr 2007 22:17:29 +0200, Adrian Bunk <[EMAIL PROTECTED]> escribió: > Bugzilla might not be perfect, but it works and it's better than doing > it by hand. The good thing about the wiki is that it doesn't exclude bugzilla. It's just a "regressions list", it doesn't intends to replace bugzilla. If a bug doesn't gets fixed for a while, I don't think it's very useful to keep it forever in the list like you do in the bugzilla, because I don't think it's possible to fix every single bug, and it steals you time to fix bugs that you are able to fix. It's not great but it's the best clone of you we've found 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
So far, it seems that most of people's opinion WRT to bug reporting and trackingcan be divided into 2 groups: - People who argues (and they're right) that bugzilla and web interfaces in general suck and that email + an "Adrian-like" solution works better - People who argues that a bug tracker better than a mailing list is absolutely needed (and they're right). They also argue that while bugzilla sucks, it's better than nothing. There's a common point between both groups: bugzilla sucks. The ideal solution would be to replace bugzilla with some alternative and better opensource bug tracking software, but I doubt it exists (there must be a reason why everybody uses bugzilla). A good bug tracker should feel like it makes your work easier, instead of making you feel like you're wasting time (which is what bugzilla does) I don't see why a web interface bug tracker should be bad for bug tracking, as long as it's good and integrates 100% in the mailing lists. In my humble opinion the "perfect" bug tracker for Linux should be something like this: - Has a email interface (like the Debian bug tracking database). - Has a web interface that completely follows the email threads (reading/posting), but make the comments real emails, not just database fields. If done well (unlike the current bugzilla-to-email hack), it should possible to do many nice things, like add a lkml bug report to the bug tracking database (which shouldn't be a "real" database, but just an lkml mail archive with a list of message IDs that are considered a bug and its state) by just replying the thread, CCing the bug tracker and telling him to include the thread in the database. So unless someone is willing to write such tool (which I doubt, since it doesn't looks easy), all this discussion seems pointless, and we should stick with this http://kernelnewbies.org/known_regressions page which is showing to be quite useful :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
So far, it seems that most of people's opinion WRT to bug reporting and trackingcan be divided into 2 groups: - People who argues (and they're right) that bugzilla and web interfaces in general suck and that email + an Adrian-like solution works better - People who argues that a bug tracker better than a mailing list is absolutely needed (and they're right). They also argue that while bugzilla sucks, it's better than nothing. There's a common point between both groups: bugzilla sucks. The ideal solution would be to replace bugzilla with some alternative and better opensource bug tracking software, but I doubt it exists (there must be a reason why everybody uses bugzilla). A good bug tracker should feel like it makes your work easier, instead of making you feel like you're wasting time (which is what bugzilla does) I don't see why a web interface bug tracker should be bad for bug tracking, as long as it's good and integrates 100% in the mailing lists. In my humble opinion the perfect bug tracker for Linux should be something like this: - Has a email interface (like the Debian bug tracking database). - Has a web interface that completely follows the email threads (reading/posting), but make the comments real emails, not just database fields. If done well (unlike the current bugzilla-to-email hack), it should possible to do many nice things, like add a lkml bug report to the bug tracking database (which shouldn't be a real database, but just an lkml mail archive with a list of message IDs that are considered a bug and its state) by just replying the thread, CCing the bug tracker and telling him to include the thread in the database. So unless someone is willing to write such tool (which I doubt, since it doesn't looks easy), all this discussion seems pointless, and we should stick with this http://kernelnewbies.org/known_regressions page which is showing to be quite useful :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Sun, 29 Apr 2007 22:17:29 +0200, Adrian Bunk [EMAIL PROTECTED] escribió: Bugzilla might not be perfect, but it works and it's better than doing it by hand. The good thing about the wiki is that it doesn't exclude bugzilla. It's just a regressions list, it doesn't intends to replace bugzilla. If a bug doesn't gets fixed for a while, I don't think it's very useful to keep it forever in the list like you do in the bugzilla, because I don't think it's possible to fix every single bug, and it steals you time to fix bugs that you are able to fix. It's not great but it's the best clone of you we've found 8) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Sun, 29 Apr 2007 23:10:28 +0200, Adrian Bunk [EMAIL PROTECTED] escribió: What exactly is the purpose of the 2.6.21 regressions list in the Wiki? AFAIK, submitting its contents to the list periodically CCing the developers, like you did with your lists. If developers care to fix it or not or how much Linus cares about that list before releasing a new version is another question. I think it's useful because it makes those bugs look more important than the 1600 stored in the bugzilla...it won't help to fix those 1600, but it attracts some attention over the release critical ones and encourages developers to fix them, even if not all of them get fixed. I don't think you can do many other things to get as much bugs fixed as possible, unless we reward bug fixers with weekends in the Playboy mansion. I think the fundamental question here is: is there a way to make hackers follow and fix _all_ the bugs? I'd love it was possible, but AFAIK all the projects that have tried to be ultra-stable and have adopted a policy to fullfill such goal have fallen behind of competing projects that cared more about working in improving their software. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21 known regressions (v2) (for -stable team)
El Sat, 28 Apr 2007 20:03:07 +0200, Thomas Meyer <[EMAIL PROTECTED]> escribió: > Please remove this from the regression list. This seems to be an > userspace only problem and is not related to any kernel driver: > amarok and/or audacious seems to repeatedly read/write to the X socket: OK - I added it just to be sure that there wasn't any dynticks regression, it's gone now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21 known regressions (v2) (for -stable team)
El Sat, 28 Apr 2007 20:03:07 +0200, Thomas Meyer [EMAIL PROTECTED] escribió: Please remove this from the regression list. This seems to be an userspace only problem and is not related to any kernel driver: amarok and/or audacious seems to repeatedly read/write to the X socket: OK - I added it just to be sure that there wasn't any dynticks regression, it's gone now. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Thu, 26 Apr 2007 11:42:22 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > I bet that's true even of a lot of people who are more "web oriented" than > I am. They may look at webpages, but getting notified by email is still > the wakeup call. There's a difference between "active and directed pushing Bugzilla sucks quite a lot at email, but you can answer emails and they get into the bugzilla database; and there're two mailing lists (listed in Documentation/HOWTO) that send notifications about every new bug added/modified- I know it's not the perfect email interface every hacker wants, but it's better than nothing. I suggested some time ago that it'd be useful to send every new bug notification from bugme-new to the LKML (and/or other lists). The volume should not be so high to make it so annoying that it makes it unuseful, and at least it makes the bugzilla-haters aware of the bugs reported, and since bugzilla tracks the answers to emails and the reporter email address is in the email, it makes easier for bugzilla-haters to ask for more data and try to fix the problem, without starting any browser. I can understand Adrian's resign. Bugzilla is crap, but there're users reporting bugs there and willing to cooperate to fix them, and they're not getting listened. There're even a few description of patches (ie: "line 6 in foo.c is wrong and it breaks our testing, it should read like this:") that have been sitting there for *years* and not getting merged. I guess that Adrian tried to canalize the important regressions to the hackers, and he got tired of apparently being the only one that cares about getting them fixed. So I, or anyone else, could try to do Adrian's job. But if Adrian (a guy that sends patches to make global functions static 8) got tired of doing that job, I suspect that I, or anyone else would also got tired of it even sooner. There're other big projects with probably more bug reports than linux, they don't work this way, and they look more succesful in their bug handling. So in my humble opinion there's a problem, about how the whole bug reporting/fixing process works. With the current linux development model, a good bug reporting/fixing process doesn't looks optional, since it's important to fix bugs ASAP to get the fixes into -stable. The fix may go as further as "writing our own bug tracking software" in the same way git fixed other development issues, or it may be a human issue, or a mix of the two. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Thu, 26 Apr 2007 13:02:28 -0400, Chuck Ebbert <[EMAIL PROTECTED]> escribió: > Problem is, not enough developers pay attention to the -stable > series. Adrian, maybe you could shift your attention there and > stop trying to track the bleeding edge? >From my humble POV, it's a problem that all this discussion was generated on what Adrian does or stop doing. Apparently, unless Adrian posts his list of know regressions, most of the people doesn't look at the bugzilla at all. Maybe it'd be useful to create a per-release bug tracker in the bugzilla or collect them into one of the a kernel.org's wiki, to make easier to follow the current state of all the "important" regressions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Thu, 26 Apr 2007 13:02:28 -0400, Chuck Ebbert [EMAIL PROTECTED] escribió: Problem is, not enough developers pay attention to the -stable series. Adrian, maybe you could shift your attention there and stop trying to track the bleeding edge? From my humble POV, it's a problem that all this discussion was generated on what Adrian does or stop doing. Apparently, unless Adrian posts his list of know regressions, most of the people doesn't look at the bugzilla at all. Maybe it'd be useful to create a per-release bug tracker in the bugzilla or collect them into one of the a kernel.org's wiki, to make easier to follow the current state of all the important regressions. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
El Thu, 26 Apr 2007 11:42:22 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: I bet that's true even of a lot of people who are more web oriented than I am. They may look at webpages, but getting notified by email is still the wakeup call. There's a difference between active and directed pushing Bugzilla sucks quite a lot at email, but you can answer emails and they get into the bugzilla database; and there're two mailing lists (listed in Documentation/HOWTO) that send notifications about every new bug added/modified- I know it's not the perfect email interface every hacker wants, but it's better than nothing. I suggested some time ago that it'd be useful to send every new bug notification from bugme-new to the LKML (and/or other lists). The volume should not be so high to make it so annoying that it makes it unuseful, and at least it makes the bugzilla-haters aware of the bugs reported, and since bugzilla tracks the answers to emails and the reporter email address is in the email, it makes easier for bugzilla-haters to ask for more data and try to fix the problem, without starting any browser. I can understand Adrian's resign. Bugzilla is crap, but there're users reporting bugs there and willing to cooperate to fix them, and they're not getting listened. There're even a few description of patches (ie: line 6 in foo.c is wrong and it breaks our testing, it should read like this:) that have been sitting there for *years* and not getting merged. I guess that Adrian tried to canalize the important regressions to the hackers, and he got tired of apparently being the only one that cares about getting them fixed. So I, or anyone else, could try to do Adrian's job. But if Adrian (a guy that sends patches to make global functions static 8) got tired of doing that job, I suspect that I, or anyone else would also got tired of it even sooner. There're other big projects with probably more bug reports than linux, they don't work this way, and they look more succesful in their bug handling. So in my humble opinion there's a problem, about how the whole bug reporting/fixing process works. With the current linux development model, a good bug reporting/fixing process doesn't looks optional, since it's important to fix bugs ASAP to get the fixes into -stable. The fix may go as further as writing our own bug tracking software in the same way git fixed other development issues, or it may be a human issue, or a mix of the two. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
El Wed, 18 Apr 2007 10:22:59 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> escribió: > So if you have 2 users on a machine running CPU hogs, you should *first* > try to be fair among users. If one user then runs 5 programs, and the > other one runs just 1, then the *one* program should get 50% of the CPU > time (the users fair share), and the five programs should get 10% of CPU > time each. And if one of them uses two threads, each thread should get 5%. "Fairness between users" was implemented long time ago by rik van riel (http://surriel.com/patches/2.4/2.4.19-fairsched). Some people has been asking for a functionality like that for a long time, ie: universities that want to avoid gcc processes from one student that is trying to learn how fork() works from starving the processes of rest of the students. But not only they want "fairness between users", they also want "priorities between users and/or groups of users", ie: "the 'students' group shouldn't starve the 'admins' group". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
El Wed, 18 Apr 2007 10:22:59 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: So if you have 2 users on a machine running CPU hogs, you should *first* try to be fair among users. If one user then runs 5 programs, and the other one runs just 1, then the *one* program should get 50% of the CPU time (the users fair share), and the five programs should get 10% of CPU time each. And if one of them uses two threads, each thread should get 5%. Fairness between users was implemented long time ago by rik van riel (http://surriel.com/patches/2.4/2.4.19-fairsched). Some people has been asking for a functionality like that for a long time, ie: universities that want to avoid gcc processes from one student that is trying to learn how fork() works from starving the processes of rest of the students. But not only they want fairness between users, they also want priorities between users and/or groups of users, ie: the 'students' group shouldn't starve the 'admins' group. - 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: ZFS with Linux: An Open Plea
El Tue, 17 Apr 2007 15:47:32 +0200 (CEST), Tomasz Kłoczko <[EMAIL PROTECTED]> escribió: > Realy can't or don't want (?) Relicensing the whole kernel under the CDDL just to be able to get ZFS is not going to happen (I bet that rewriting ZFS is easier than relicensing a large piece of software with thousand of different copyrigth owners ;) Either Sun relicenses Solaris under a GPL-compatible license (which may happen, as Sun's CEO has said they may relicense it under the GPL3), or Linux won't get ZFS except using the FUSE backend. If you miss ZFS, you always can use solaris. - 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: ZFS with Linux: An Open Plea
El Tue, 17 Apr 2007 15:47:32 +0200 (CEST), Tomasz Kłoczko [EMAIL PROTECTED] escribió: Realy can't or don't want (?) Relicensing the whole kernel under the CDDL just to be able to get ZFS is not going to happen (I bet that rewriting ZFS is easier than relicensing a large piece of software with thousand of different copyrigth owners ;) Either Sun relicenses Solaris under a GPL-compatible license (which may happen, as Sun's CEO has said they may relicense it under the GPL3), or Linux won't get ZFS except using the FUSE backend. If you miss ZFS, you always can use solaris. - 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: ZFS with Linux: An Open Plea
El Mon, 16 Apr 2007 17:46:50 +0200 (CEST), Tomasz Kłoczko <[EMAIL PROTECTED]> escribió: > also some other interestig numbers can be founnd on: > http://milek.blogspot.com/2006/08/hw-raid-vs-zfs-software-raid-part-ii.html So software raid can be faster than HW raid. News at 11. - 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: ZFS with Linux: An Open Plea
El Mon, 16 Apr 2007 17:46:50 +0200 (CEST), Tomasz Kłoczko [EMAIL PROTECTED] escribió: also some other interestig numbers can be founnd on: http://milek.blogspot.com/2006/08/hw-raid-vs-zfs-software-raid-part-ii.html So software raid can be faster than HW raid. News at 11. - 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: Free Linux Driver Development!
El Tue, 30 Jan 2007 20:31:01 +0100 (MET), Jan Engelhardt <[EMAIL PROTECTED]> escribió: > Don't they claim 50+? Already browsing > ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2 > screenfuls [à 25]. I don't know exactly how many architectures does netbsd run, but Linux seems to support arches that netbsd doesn't, like: 64 bit MIPS, PPC 970 (available in netbsd but not yet integrated i think), Cell, S390, M32R, Nec v850, frv, cris?, xtensa, mmuless cpus (apparently there're lots of mmuless cpus), Itanium (netbsd development ongoing) Sure, Linux doesn't support vax and the like, but it does support lots of architectures that matter. In http://netbsd.org/Ports/#ports-by-cpu there's a more Linux-like view of the architectures supported. Although Netbsd people will argue that porting a architecture to Linux is more difficult and that Linux gets support just because there's a lot of $$$ around it. Anyway, even if Linux wasn't the OS with more architectures supported it'd be the _second_ on the list. Which is quite impressive anyway, and nothing to be ashamed of. - 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: Free Linux Driver Development!
El Tue, 30 Jan 2007 11:10:20 -0800, Greg KH <[EMAIL PROTECTED]> escribió: > Any specific examples? I have a long list of people who wish to write > new drivers but just don't know which hardware is not yet supported. It'd be interesting to join forces with the BSD guys in this field, they surely support initiatives like this! - 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: Free Linux Driver Development!
El Tue, 30 Jan 2007 11:10:20 -0800, Greg KH [EMAIL PROTECTED] escribió: Any specific examples? I have a long list of people who wish to write new drivers but just don't know which hardware is not yet supported. It'd be interesting to join forces with the BSD guys in this field, they surely support initiatives like this! - 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: Free Linux Driver Development!
El Tue, 30 Jan 2007 20:31:01 +0100 (MET), Jan Engelhardt [EMAIL PROTECTED] escribió: Don't they claim 50+? Already browsing ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2 screenfuls [à 25]. I don't know exactly how many architectures does netbsd run, but Linux seems to support arches that netbsd doesn't, like: 64 bit MIPS, PPC 970 (available in netbsd but not yet integrated i think), Cell, S390, M32R, Nec v850, frv, cris?, xtensa, mmuless cpus (apparently there're lots of mmuless cpus), Itanium (netbsd development ongoing) Sure, Linux doesn't support vax and the like, but it does support lots of architectures that matter. In http://netbsd.org/Ports/#ports-by-cpu there's a more Linux-like view of the architectures supported. Although Netbsd people will argue that porting a architecture to Linux is more difficult and that Linux gets support just because there's a lot of $$$ around it. Anyway, even if Linux wasn't the OS with more architectures supported it'd be the _second_ on the list. Which is quite impressive anyway, and nothing to be ashamed of. - 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/
"Please report the result to linux-kernel to fix this permanently"
There's a bug in the bugzilla (http://bugzilla.kernel.org/show_bug.cgi?id=7531) that is asking to be reported here. The full dmesg (with and without 'pci=assign-busses') can be found in the link. [17179574.14] Boot video device is :01:05.0 [17179574.14] PCI: Transparent bridge - :00:14.4 [17179574.14] PCI: Bus #06 (-#09) is hidden behind transparent bridge #05 (-#05) (try 'pci=assign-busses') [17179574.14] Please report the result to linux-kernel to fix this permanently [17179574.14] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [17179574.144000] ACPI: PCI Interrupt Link [LNKA] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKB] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKC] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKD] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKE] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKF] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKG] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKH] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: Embedded Controller [EC0] (gpe 24) interrupt mode. [17179574.148000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P_._PRT] [17179574.148000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] - 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/
Please report the result to linux-kernel to fix this permanently
There's a bug in the bugzilla (http://bugzilla.kernel.org/show_bug.cgi?id=7531) that is asking to be reported here. The full dmesg (with and without 'pci=assign-busses') can be found in the link. [17179574.14] Boot video device is :01:05.0 [17179574.14] PCI: Transparent bridge - :00:14.4 [17179574.14] PCI: Bus #06 (-#09) is hidden behind transparent bridge #05 (-#05) (try 'pci=assign-busses') [17179574.14] Please report the result to linux-kernel to fix this permanently [17179574.14] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [17179574.144000] ACPI: PCI Interrupt Link [LNKA] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKB] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKC] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKD] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKE] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKF] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKG] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: PCI Interrupt Link [LNKH] (IRQs 10 11) *0, disabled. [17179574.144000] ACPI: Embedded Controller [EC0] (gpe 24) interrupt mode. [17179574.148000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P_._PRT] [17179574.148000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
El Tue, 19 Dec 2006 11:46:30 -0500, Gene Heskett <[EMAIL PROTECTED]> escribió: > IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids' > > That file apparently doesn't exist on an FC6 i686 system Indeed, I forgot to document that. Ubuntu has it there (package pciutils), and update-pciids updates the file from http://pciids.sourceforge.net/pci.ids. So you can download that file and change the path in the script. Anyway, you can find the output at http://www.terra.es/personal/diegocg/list.txt - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny <[EMAIL PROTECTED]>
escribió:
> I had another, probably crazy idea. Would it be possible to utilize the
> current vendor/device PCI ID database to create Linux friendliness matrix
> site?
I've a script (attached) that looks into /lib/modules/`uname -r`/modules.pcimap,
looks up the IDs in the pci id database and print the real name. At least it
shows
it's possible to know what devices are supported ...
#!/usr/bin/python
def pciids_to_names(ids):
# Only the last four numbers of the ids have useful info
vendorid = ids[1][6:10]
deviceid = ids[2][6:10]
subvendorid = ids[3][6:10]
subdeviceid = ids[4][6:10]
result = [ids[0], "", "", "", "", ""]
pciids = open('/usr/share/misc/pci.ids', 'r')
# Search for vendor
for line in pciids:
if line[0] == "#" or line[0] == "C" or line[0] == "\t":
continue
if line[0:4] == vendorid:
result[1] = line[6:].strip() # Vendor name
break
if result[1] == "": # Vendor not found
return result
# Search for a device
for line in pciids:
if line[0] != "\t":
continue
if line[1:5] == deviceid:
result[2] = line[7:].strip() # Device name
break
# Search a subsystem name
for line in pciids:
if line[2:11] == subvendorid + " " + subdeviceid: # subsystem name
result[3] = line[12:].strip() # The subvendor and subdevice ids point to a _single_ subsystem name
break
# Search a class name
if ids[5][4:6] == "00" and ids[5][6:8] == "00" and ids[5][6:8] == "00":
pass # void class ids
else:
pciids.seek(0)
# Search a class name
for line in pciids:
if line[0] == "C":
if line[2:4] == ids[5][4:6]: # found class
result[4] = line[6:].strip() # appended class name
break
if result[4] == "": # class not found
return result
# Search subclass name
for line in pciids:
if line [1:3] == ids[5][6:8]:
result[5] = line[5:].strip()
break
return result
### Start of the code flow ###
import platform
pcimap = open('/lib/modules/' + platform.uname()[2] + '/modules.pcimap', 'r')
previousmodule = ""
for line in pcimap:
if line[0] == "#" or line[0] == " ": continue
data = line.split(None)
ret = pciids_to_names(data)
if ret[0] != previousmodule:
previousmodule = ret[0]
print "Driver: " + previousmodule
if ret[2] == "":
output = "\tDevice NOT found in the pciid database: " + repr(data)
else:
output = "\tDevice: " + ret[2] + " (deviceid " + data[2][6:] + "); made by " + ret[1] + " (vendorid " + data[1][6:] + ")"
if ret[3] != "": output += "; Subsystem: " + ret[3] + " (subsysid " + data[3][6:] + ":" + data[4][6:] + ")"
if ret[4] != "": output += "; Class: " + ret[4]
if ret[5] != "": output += "; Subclass: " + ret[5]
print output
