Re: [Panic - Bisected] f1a18a10566081abfce1649c2f3884b28fff7372 cases panic on boot
On 22 July 2013 23:11, Linus Torvalds wrote: > On 22 July 2013 21:45, Kevin Winchester wrote: >> I have found that the new CPU Package temperature thermal driver introduced >> in this merge window causes my HP laptop to panic on boot. > > I just merged Zhang's pull request that should contain a fix for this, > but was planning on the allmoconfig build finishing before pushing it > out. Give me a few minutes.. > Yes, I have tested with your latest tree, and it works even with the driver enabled. Thanks! Kevin -- 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: [Panic - Bisected] f1a18a10566081abfce1649c2f3884b28fff7372 cases panic on boot
On 22 July 2013 23:11, Linus Torvalds torva...@linux-foundation.org wrote: On 22 July 2013 21:45, Kevin Winchester kjwinches...@gmail.com wrote: I have found that the new CPU Package temperature thermal driver introduced in this merge window causes my HP laptop to panic on boot. I just merged Zhang's pull request that should contain a fix for this, but was planning on the allmoconfig build finishing before pushing it out. Give me a few minutes.. Yes, I have tested with your latest tree, and it works even with the driver enabled. Thanks! Kevin -- 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: [Panic - Bisected] f1a18a10566081abfce1649c2f3884b28fff7372 cases panic on boot
Sorry, forgot to change gmail to plain text mode, so the mailing lists rejected this. On 22 July 2013 21:45, Kevin Winchester wrote: > I have found that the new CPU Package temperature thermal driver introduced > in this merge window causes my HP laptop to panic on boot. > > An image of the panic information can be found here: > > https://lh6.googleusercontent.com/-lA_vInpGkIs/Ue3FySjGOoI/AG0/fRmh0Qjcs9o/w1135-h851-no/Linux+Screenshots+-+1 > > I bisected to find the offending commit, since the error was quite > reproducible. > > # first bad commit: [f1a18a10566081abfce1649c2f3884b28fff7372] Thermal: CPU > Package temperature thermal > > I'll next try: > > - disabling the driver in my config (I enabled it when asked since thermal > control seems like a good thing) > - Reverting the patch on top of v3.11-rc2 > > > What other info can I provide or steps can I take to help with this? > > > Thanks, > Kevin > -- 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: [Panic - Bisected] f1a18a10566081abfce1649c2f3884b28fff7372 cases panic on boot
Sorry, forgot to change gmail to plain text mode, so the mailing lists rejected this. On 22 July 2013 21:45, Kevin Winchester kjwinches...@gmail.com wrote: I have found that the new CPU Package temperature thermal driver introduced in this merge window causes my HP laptop to panic on boot. An image of the panic information can be found here: https://lh6.googleusercontent.com/-lA_vInpGkIs/Ue3FySjGOoI/AG0/fRmh0Qjcs9o/w1135-h851-no/Linux+Screenshots+-+1 I bisected to find the offending commit, since the error was quite reproducible. # first bad commit: [f1a18a10566081abfce1649c2f3884b28fff7372] Thermal: CPU Package temperature thermal I'll next try: - disabling the driver in my config (I enabled it when asked since thermal control seems like a good thing) - Reverting the patch on top of v3.11-rc2 What other info can I provide or steps can I take to help with this? Thanks, Kevin -- 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: broken suspend to ram with velocity driver
b5: root hub lost power or was reset Feb 25 20:19:14 alekhine kernel: [ 73.934336] ACPI: PCI Interrupt :00:10.4[C] -> GSI 21 (level, low) -> IRQ 21 Feb 25 20:19:14 alekhine kernel: [ 73.945209] ACPI: PCI Interrupt :00:11.5[C] -> GSI 22 (level, low) -> IRQ 22 Feb 25 20:19:14 alekhine kernel: [ 73.947465] ACPI: PCI Interrupt :01:00.0[A] -> GSI 16 (level, low) -> IRQ 16 Feb 25 20:19:14 alekhine kernel: [ 73.947660] sd 3:0:0:0: [sda] Starting disk Feb 25 20:19:14 alekhine kernel: [ 74.183122] ata3.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.183122] ata3.01: ACPI cmd ef/03:42:00:00:00:b0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.336028] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.336028] ata3.00: ACPI cmd ef/03:42:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.491252] ata3.00: configured for UDMA/33 Feb 25 20:19:14 alekhine kernel: [ 74.678330] ata3.01: configured for UDMA/33 Feb 25 20:19:14 alekhine kernel: [ 78.168897] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 78.168897] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 78.172976] ata4.00: configured for UDMA/100 Feb 25 20:19:14 alekhine kernel: [ 78.177133] sd 3:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) Feb 25 20:19:14 alekhine kernel: [ 78.177133] sd 3:0:0:0: [sda] Write Protect is off Feb 25 20:19:14 alekhine kernel: [ 78.177133] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Feb 25 20:19:14 alekhine kernel: [ 78.720991] Restarting tasks ... <6>usb 2-1: USB disconnect, address 2 Feb 25 20:19:14 alekhine kernel: [ 78.766838] done. Feb 25 20:19:14 alekhine kernel: [ 78.951998] usb 2-1: new low speed USB device using uhci_hcd and address 4 Feb 25 20:19:14 alekhine kernel: [ 79.114037] usb 2-1: configuration #1 chosen from 1 choice Feb 25 20:19:14 alekhine kernel: [ 79.138166] input: Logitech USB Mouse as /devices/pci:00/:00:10.0/usb2/2-1/2-1:1.0/input/input5 Feb 25 20:19:14 alekhine kernel: [ 79.180828] input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:10.0-1 Feb 25 20:19:14 alekhine kernel: [ 79.181059] usb 2-2: USB disconnect, address 3 Feb 25 20:19:15 alekhine kernel: [ 79.436567] usb 2-2: new low speed USB device using uhci_hcd and address 5 Feb 25 20:19:15 alekhine kernel: [ 79.606180] usb 2-2: configuration #1 chosen from 1 choice Feb 25 20:19:15 alekhine kernel: [ 79.623893] input: Microsoft Microsoft Digital Media Pro Keyboard as /devices/pci:00/:00:10.0/usb2/2-2/2-2:1.0/input/input6 Feb 25 20:19:15 alekhine kernel: [ 79.663140] input: USB HID v1.11 Keyboard [Microsoft Microsoft Digital Media Pro Keyboard] on usb-:00:10.0-2 Feb 25 20:19:15 alekhine kernel: [ 79.697610] input: Microsoft Microsoft Digital Media Pro Keyboard as /devices/pci:00/:00:10.0/usb2/2-2/2-2:1.1/input/input7 Feb 25 20:19:15 alekhine kernel: [ 79.721948] input: USB HID v1.11 Device [Microsoft Microsoft Digital Media Pro Keyboard] on usb-:00:10.0-2 I don't see anything there that would explain the failure, but the console never comes back, and I am forced to hard reset the box. Anything else I can try? Thanks, -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: broken suspend to ram with velocity driver
alekhine kernel: [ 73.947660] sd 3:0:0:0: [sda] Starting disk Feb 25 20:19:14 alekhine kernel: [ 74.183122] ata3.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.183122] ata3.01: ACPI cmd ef/03:42:00:00:00:b0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.336028] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.336028] ata3.00: ACPI cmd ef/03:42:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 74.491252] ata3.00: configured for UDMA/33 Feb 25 20:19:14 alekhine kernel: [ 74.678330] ata3.01: configured for UDMA/33 Feb 25 20:19:14 alekhine kernel: [ 78.168897] ata4.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 78.168897] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out Feb 25 20:19:14 alekhine kernel: [ 78.172976] ata4.00: configured for UDMA/100 Feb 25 20:19:14 alekhine kernel: [ 78.177133] sd 3:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) Feb 25 20:19:14 alekhine kernel: [ 78.177133] sd 3:0:0:0: [sda] Write Protect is off Feb 25 20:19:14 alekhine kernel: [ 78.177133] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Feb 25 20:19:14 alekhine kernel: [ 78.720991] Restarting tasks ... 6usb 2-1: USB disconnect, address 2 Feb 25 20:19:14 alekhine kernel: [ 78.766838] done. Feb 25 20:19:14 alekhine kernel: [ 78.951998] usb 2-1: new low speed USB device using uhci_hcd and address 4 Feb 25 20:19:14 alekhine kernel: [ 79.114037] usb 2-1: configuration #1 chosen from 1 choice Feb 25 20:19:14 alekhine kernel: [ 79.138166] input: Logitech USB Mouse as /devices/pci:00/:00:10.0/usb2/2-1/2-1:1.0/input/input5 Feb 25 20:19:14 alekhine kernel: [ 79.180828] input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:10.0-1 Feb 25 20:19:14 alekhine kernel: [ 79.181059] usb 2-2: USB disconnect, address 3 Feb 25 20:19:15 alekhine kernel: [ 79.436567] usb 2-2: new low speed USB device using uhci_hcd and address 5 Feb 25 20:19:15 alekhine kernel: [ 79.606180] usb 2-2: configuration #1 chosen from 1 choice Feb 25 20:19:15 alekhine kernel: [ 79.623893] input: Microsoft MicrosoftAE Digital Media Pro Keyboard as /devices/pci:00/:00:10.0/usb2/2-2/2-2:1.0/input/input6 Feb 25 20:19:15 alekhine kernel: [ 79.663140] input: USB HID v1.11 Keyboard [Microsoft MicrosoftAE Digital Media Pro Keyboard] on usb-:00:10.0-2 Feb 25 20:19:15 alekhine kernel: [ 79.697610] input: Microsoft MicrosoftAE Digital Media Pro Keyboard as /devices/pci:00/:00:10.0/usb2/2-2/2-2:1.1/input/input7 Feb 25 20:19:15 alekhine kernel: [ 79.721948] input: USB HID v1.11 Device [Microsoft MicrosoftAE Digital Media Pro Keyboard] on usb-:00:10.0-2 I don't see anything there that would explain the failure, but the console never comes back, and I am forced to hard reset the box. Anything else I can try? Thanks, -- Kevin Winchester -- 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-next: Tree for Feb 24
Rafael J. Wysocki wrote:
> On Monday, 25 of February 2008, Kevin Winchester wrote:
>> Rafael J. Wysocki wrote:
>>> On Sunday, 24 of February 2008, Kevin Winchester wrote:
>>>
>>>> Today was different - I attempted to suspend and resume from the console,
>>>> and the machine did not come back up. I found the following in my log -
>>>> any help would be appreciated.
>>>>
>>>> Feb 24 13:59:56 alekhine kernel: [ 456.497875] PM: Syncing filesystems
>>>> ... done.
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.507273] Freezing user space
>>>> processes ... (elapsed 0.00 seconds) done.
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.510447] Freezing remaining
>>>> freezable tasks ... (elapsed 0.00 seconds) done.
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.510754] ACPI: Preparing to enter
>>>> system sleep state S3
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.612370] Suspending console(s)
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.616254] sd 3:0:0:0: [sda]
>>>> Synchronizing SCSI cache
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.616521] sd 3:0:0:0: [sda] Stopping
>>>> disk
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.618221] ACPI: PCI interrupt for
>>>> device :00:11.5 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.630296] ACPI: PCI interrupt for
>>>> device :00:10.4 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.641085] ACPI: PCI interrupt for
>>>> device :00:10.3 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.651877] ACPI: PCI interrupt for
>>>> device :00:10.2 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.662716] ACPI: PCI interrupt for
>>>> device :00:10.1 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.673550] ACPI: PCI interrupt for
>>>> device :00:10.0 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.684385] ACPI: PCI interrupt for
>>>> device :00:0f.1 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.695056] ACPI: PCI interrupt for
>>>> device :00:0f.0 disabled
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] 5 locks held by bash/2929:
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #0:
>>>> (>mutex){--..}, at: [] sysfs_write_file+0x25/0xe3
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #1: (pm_mutex){--..},
>>>> at: [] enter_state+0xea/0x100
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #2:
>>>> (pm_sleep_rwsem){}, at: [] device_suspend+0x25/0x251
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #3:
>>>> (>update_lock#2){--..}, at: [] abituguru_suspend+0x13/0x18
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #4: (>lock){++..},
>>>> at: [] velocity_suspend+0x37/0x302
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] irq event stamp: 19374
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last enabled at
>>>> (19373): [] __mutex_unlock_slowpath+0xd5/0xef
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last disabled at
>>>> (19374): [] _spin_lock_irqsave+0xf/0x3c
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last enabled at
>>>> (18484): [] __do_softirq+0x99/0x9e
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last disabled at
>>>> (18479): [] do_softirq+0x58/0xa8
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] Pid: 2929, comm: bash Not
>>>> tainted 2.6.25-rc2-next-20080224 #58
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
>>>> __schedule_bug+0x58/0x5f
>>>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
>>>> schedule+0x67/0x3b3
>>> Well, could you check what's at schedule+0x67, please?
>> Is this how I would do this? I tried schedule+0x67, but it just showed me
>> the beginning of profile_hit.
>>
>> (gdb) l *(schedule+0x66)
>> 0xc0325b42 is in schedule (kernel/sched.c:3836).
>> 3831 * Test if we are atomic. Since do_exit() needs to call into
>> 3832 * schedule() atomically, we ignore that path for now.
>> 3833 * Otherwise, whine if we are scheduling when we should not be.
>> 3834 */
>> 3835 if (unlikely(in_atomic_preempt_off()) &&
>> unlikely(!prev->exit_state))
>> 3836 __s
Re: linux-next: Tree for Feb 24
Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Kevin Winchester wrote:
>
>> Today was different - I attempted to suspend and resume from the console,
>> and the machine did not come back up. I found the following in my log -
>> any help would be appreciated.
>>
>> Feb 24 13:59:56 alekhine kernel: [ 456.497875] PM: Syncing filesystems ...
>> done.
>> Feb 24 14:00:20 alekhine kernel: [ 456.507273] Freezing user space
>> processes ... (elapsed 0.00 seconds) done.
>> Feb 24 14:00:20 alekhine kernel: [ 456.510447] Freezing remaining freezable
>> tasks ... (elapsed 0.00 seconds) done.
>> Feb 24 14:00:20 alekhine kernel: [ 456.510754] ACPI: Preparing to enter
>> system sleep state S3
>> Feb 24 14:00:20 alekhine kernel: [ 456.612370] Suspending console(s)
>> Feb 24 14:00:20 alekhine kernel: [ 456.616254] sd 3:0:0:0: [sda]
>> Synchronizing SCSI cache
>> Feb 24 14:00:20 alekhine kernel: [ 456.616521] sd 3:0:0:0: [sda] Stopping
>> disk
>> Feb 24 14:00:20 alekhine kernel: [ 456.618221] ACPI: PCI interrupt for
>> device :00:11.5 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.630296] ACPI: PCI interrupt for
>> device :00:10.4 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.641085] ACPI: PCI interrupt for
>> device :00:10.3 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.651877] ACPI: PCI interrupt for
>> device :00:10.2 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.662716] ACPI: PCI interrupt for
>> device :00:10.1 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.673550] ACPI: PCI interrupt for
>> device :00:10.0 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.684385] ACPI: PCI interrupt for
>> device :00:0f.1 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.695056] ACPI: PCI interrupt for
>> device :00:0f.0 disabled
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] 5 locks held by bash/2929:
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #0:
>> (>mutex){--..}, at: [] sysfs_write_file+0x25/0xe3
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #1: (pm_mutex){--..}, at:
>> [] enter_state+0xea/0x100
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #2:
>> (pm_sleep_rwsem){}, at: [] device_suspend+0x25/0x251
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #3:
>> (>update_lock#2){--..}, at: [] abituguru_suspend+0x13/0x18
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] #4: (>lock){++..},
>> at: [] velocity_suspend+0x37/0x302
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] irq event stamp: 19374
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last enabled at
>> (19373): [] __mutex_unlock_slowpath+0xd5/0xef
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last disabled at
>> (19374): [] _spin_lock_irqsave+0xf/0x3c
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last enabled at
>> (18484): [] __do_softirq+0x99/0x9e
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last disabled at
>> (18479): [] do_softirq+0x58/0xa8
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] Pid: 2929, comm: bash Not
>> tainted 2.6.25-rc2-next-20080224 #58
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
>> __schedule_bug+0x58/0x5f
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
>> schedule+0x67/0x3b3
>
> Well, could you check what's at schedule+0x67, please?
Is this how I would do this? I tried schedule+0x67, but it just showed me the
beginning of profile_hit.
(gdb) l *(schedule+0x66)
0xc0325b42 is in schedule (kernel/sched.c:3836).
3831 * Test if we are atomic. Since do_exit() needs to call into
3832 * schedule() atomically, we ignore that path for now.
3833 * Otherwise, whine if we are scheduling when we should not be.
3834 */
3835if (unlikely(in_atomic_preempt_off()) &&
unlikely(!prev->exit_state))
3836__schedule_bug(prev);
3837
3838profile_hit(SCHED_PROFILING, __builtin_return_address(0));
3839
3840schedstat_inc(this_rq(), sched_count);
It appears that we are scheduling when we should not be...
>
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
>> __mod_timer+0x8d/0x98
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
>> schedule_timeout+0x73/0x91
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
>> process_timeout+0x0/0xa
>> Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
>> schedule_timeout_uninterruptible+0x14/0x16
>> Feb 24 14:00:20 alekhine kernel: [ 456.70
Re: linux-next: Tree for Feb 24
Stephen Rothwell wrote:
> Hi all,
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log files
> in the Next directory. Between each merge, the tree was built with
> allmodconfig for both powerpc and x86_64.
>
> There only one minor merge problem and a few build failures (the two in
> Linus' tree have been fixed and the other reported).
>
> We are up to 32 trees, more are welcome (even if they are currently
> empty).
>
> Status of my local build tests is at
> http://kisskb.ellerman.id.au/kisskb/branch/9/.
>
I tried something with this tree that I haven't tried in a while - Suspend
to RAM. It has not often worked for me in the past with any tree, but
normally there isn't any information in the log that indicates the cause of
the failure.
Today was different - I attempted to suspend and resume from the console,
and the machine did not come back up. I found the following in my log -
any help would be appreciated.
Feb 24 13:59:56 alekhine kernel: [ 456.497875] PM: Syncing filesystems ...
done.
Feb 24 14:00:20 alekhine kernel: [ 456.507273] Freezing user space processes
... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510447] Freezing remaining freezable
tasks ... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510754] ACPI: Preparing to enter system
sleep state S3
Feb 24 14:00:20 alekhine kernel: [ 456.612370] Suspending console(s)
Feb 24 14:00:20 alekhine kernel: [ 456.616254] sd 3:0:0:0: [sda] Synchronizing
SCSI cache
Feb 24 14:00:20 alekhine kernel: [ 456.616521] sd 3:0:0:0: [sda] Stopping disk
Feb 24 14:00:20 alekhine kernel: [ 456.618221] ACPI: PCI interrupt for device
:00:11.5 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.630296] ACPI: PCI interrupt for device
:00:10.4 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.641085] ACPI: PCI interrupt for device
:00:10.3 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.651877] ACPI: PCI interrupt for device
:00:10.2 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.662716] ACPI: PCI interrupt for device
:00:10.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.673550] ACPI: PCI interrupt for device
:00:10.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.684385] ACPI: PCI interrupt for device
:00:0f.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.695056] ACPI: PCI interrupt for device
:00:0f.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.705856] 5 locks held by bash/2929:
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #0: (>mutex){--..},
at: [] sysfs_write_file+0x25/0xe3
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #1: (pm_mutex){--..}, at:
[] enter_state+0xea/0x100
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #2: (pm_sleep_rwsem){},
at: [] device_suspend+0x25/0x251
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #3:
(>update_lock#2){--..}, at: [] abituguru_suspend+0x13/0x18
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #4: (>lock){++..}, at:
[] velocity_suspend+0x37/0x302
Feb 24 14:00:20 alekhine kernel: [ 456.705856] irq event stamp: 19374
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last enabled at
(19373): [] __mutex_unlock_slowpath+0xd5/0xef
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last disabled at
(19374): [] _spin_lock_irqsave+0xf/0x3c
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last enabled at
(18484): [] __do_softirq+0x99/0x9e
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last disabled at
(18479): [] do_softirq+0x58/0xa8
Feb 24 14:00:20 alekhine kernel: [ 456.705856] Pid: 2929, comm: bash Not
tainted 2.6.25-rc2-next-20080224 #58
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
__schedule_bug+0x58/0x5f
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
schedule+0x67/0x3b3
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
__mod_timer+0x8d/0x98
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
schedule_timeout+0x73/0x91
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
process_timeout+0x0/0xa
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
schedule_timeout_uninterruptible+0x14/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] msleep+0x10/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
pci_set_power_state+0x17f/0x200
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
velocity_suspend+0x2e9/0x302
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
mark_held_locks+0x4e/0x66
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
__mutex_unlock_slowpath+0xd5/0xef
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [] ?
trace_hardirqs_on+0xe5/0x120
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
pci_device_suspend+0x1b/0x4b
Feb 24 14:00:20 alekhine kernel: [ 456.705856] []
device_suspend+0x192/0x251
Feb 24
Re: linux-next: Tree for Feb 24
Stephen Rothwell wrote:
Hi all,
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
allmodconfig for both powerpc and x86_64.
There only one minor merge problem and a few build failures (the two in
Linus' tree have been fixed and the other reported).
We are up to 32 trees, more are welcome (even if they are currently
empty).
Status of my local build tests is at
http://kisskb.ellerman.id.au/kisskb/branch/9/.
I tried something with this tree that I haven't tried in a while - Suspend
to RAM. It has not often worked for me in the past with any tree, but
normally there isn't any information in the log that indicates the cause of
the failure.
Today was different - I attempted to suspend and resume from the console,
and the machine did not come back up. I found the following in my log -
any help would be appreciated.
Feb 24 13:59:56 alekhine kernel: [ 456.497875] PM: Syncing filesystems ...
done.
Feb 24 14:00:20 alekhine kernel: [ 456.507273] Freezing user space processes
... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510447] Freezing remaining freezable
tasks ... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510754] ACPI: Preparing to enter system
sleep state S3
Feb 24 14:00:20 alekhine kernel: [ 456.612370] Suspending console(s)
Feb 24 14:00:20 alekhine kernel: [ 456.616254] sd 3:0:0:0: [sda] Synchronizing
SCSI cache
Feb 24 14:00:20 alekhine kernel: [ 456.616521] sd 3:0:0:0: [sda] Stopping disk
Feb 24 14:00:20 alekhine kernel: [ 456.618221] ACPI: PCI interrupt for device
:00:11.5 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.630296] ACPI: PCI interrupt for device
:00:10.4 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.641085] ACPI: PCI interrupt for device
:00:10.3 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.651877] ACPI: PCI interrupt for device
:00:10.2 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.662716] ACPI: PCI interrupt for device
:00:10.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.673550] ACPI: PCI interrupt for device
:00:10.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.684385] ACPI: PCI interrupt for device
:00:0f.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.695056] ACPI: PCI interrupt for device
:00:0f.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.705856] 5 locks held by bash/2929:
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #0: (buffer-mutex){--..},
at: [c018960c] sysfs_write_file+0x25/0xe3
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #1: (pm_mutex){--..}, at:
[c0138c54] enter_state+0xea/0x100
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #2: (pm_sleep_rwsem){},
at: [c023c4b8] device_suspend+0x25/0x251
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #3:
(data-update_lock#2){--..}, at: [c029cb2b] abituguru_suspend+0x13/0x18
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #4: (vptr-lock){++..}, at:
[c0244665] velocity_suspend+0x37/0x302
Feb 24 14:00:20 alekhine kernel: [ 456.705856] irq event stamp: 19374
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last enabled at
(19373): [c0326664] __mutex_unlock_slowpath+0xd5/0xef
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last disabled at
(19374): [c0327bca] _spin_lock_irqsave+0xf/0x3c
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last enabled at
(18484): [c011e6ba] __do_softirq+0x99/0x9e
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last disabled at
(18479): [c0104f15] do_softirq+0x58/0xa8
Feb 24 14:00:20 alekhine kernel: [ 456.705856] Pid: 2929, comm: bash Not
tainted 2.6.25-rc2-next-20080224 #58
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01177c7]
__schedule_bug+0x58/0x5f
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0325b43]
schedule+0x67/0x3b3
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0121c39] ?
__mod_timer+0x8d/0x98
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326043]
schedule_timeout+0x73/0x91
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c012185c] ?
process_timeout+0x0/0xa
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326075]
schedule_timeout_uninterruptible+0x14/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0121c54] msleep+0x10/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01e0e51]
pci_set_power_state+0x17f/0x200
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0244917]
velocity_suspend+0x2e9/0x302
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0133854] ?
mark_held_locks+0x4e/0x66
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326664] ?
__mutex_unlock_slowpath+0xd5/0xef
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01339dd] ?
trace_hardirqs_on+0xe5/0x120
Feb
Re: linux-next: Tree for Feb 24
Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Kevin Winchester wrote:
Today was different - I attempted to suspend and resume from the console,
and the machine did not come back up. I found the following in my log -
any help would be appreciated.
Feb 24 13:59:56 alekhine kernel: [ 456.497875] PM: Syncing filesystems ...
done.
Feb 24 14:00:20 alekhine kernel: [ 456.507273] Freezing user space
processes ... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510447] Freezing remaining freezable
tasks ... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510754] ACPI: Preparing to enter
system sleep state S3
Feb 24 14:00:20 alekhine kernel: [ 456.612370] Suspending console(s)
Feb 24 14:00:20 alekhine kernel: [ 456.616254] sd 3:0:0:0: [sda]
Synchronizing SCSI cache
Feb 24 14:00:20 alekhine kernel: [ 456.616521] sd 3:0:0:0: [sda] Stopping
disk
Feb 24 14:00:20 alekhine kernel: [ 456.618221] ACPI: PCI interrupt for
device :00:11.5 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.630296] ACPI: PCI interrupt for
device :00:10.4 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.641085] ACPI: PCI interrupt for
device :00:10.3 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.651877] ACPI: PCI interrupt for
device :00:10.2 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.662716] ACPI: PCI interrupt for
device :00:10.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.673550] ACPI: PCI interrupt for
device :00:10.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.684385] ACPI: PCI interrupt for
device :00:0f.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.695056] ACPI: PCI interrupt for
device :00:0f.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.705856] 5 locks held by bash/2929:
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #0:
(buffer-mutex){--..}, at: [c018960c] sysfs_write_file+0x25/0xe3
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #1: (pm_mutex){--..}, at:
[c0138c54] enter_state+0xea/0x100
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #2:
(pm_sleep_rwsem){}, at: [c023c4b8] device_suspend+0x25/0x251
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #3:
(data-update_lock#2){--..}, at: [c029cb2b] abituguru_suspend+0x13/0x18
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #4: (vptr-lock){++..},
at: [c0244665] velocity_suspend+0x37/0x302
Feb 24 14:00:20 alekhine kernel: [ 456.705856] irq event stamp: 19374
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last enabled at
(19373): [c0326664] __mutex_unlock_slowpath+0xd5/0xef
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last disabled at
(19374): [c0327bca] _spin_lock_irqsave+0xf/0x3c
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last enabled at
(18484): [c011e6ba] __do_softirq+0x99/0x9e
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last disabled at
(18479): [c0104f15] do_softirq+0x58/0xa8
Feb 24 14:00:20 alekhine kernel: [ 456.705856] Pid: 2929, comm: bash Not
tainted 2.6.25-rc2-next-20080224 #58
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01177c7]
__schedule_bug+0x58/0x5f
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0325b43]
schedule+0x67/0x3b3
Well, could you check what's at schedule+0x67, please?
Is this how I would do this? I tried schedule+0x67, but it just showed me the
beginning of profile_hit.
(gdb) l *(schedule+0x66)
0xc0325b42 is in schedule (kernel/sched.c:3836).
3831 * Test if we are atomic. Since do_exit() needs to call into
3832 * schedule() atomically, we ignore that path for now.
3833 * Otherwise, whine if we are scheduling when we should not be.
3834 */
3835if (unlikely(in_atomic_preempt_off())
unlikely(!prev-exit_state))
3836__schedule_bug(prev);
3837
3838profile_hit(SCHED_PROFILING, __builtin_return_address(0));
3839
3840schedstat_inc(this_rq(), sched_count);
It appears that we are scheduling when we should not be...
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0121c39] ?
__mod_timer+0x8d/0x98
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326043]
schedule_timeout+0x73/0x91
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c012185c] ?
process_timeout+0x0/0xa
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326075]
schedule_timeout_uninterruptible+0x14/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0121c54]
msleep+0x10/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01e0e51]
pci_set_power_state+0x17f/0x200
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0244917]
velocity_suspend+0x2e9/0x302
velocity_suspend() seems to be at fault.
(gdb) l *(velocity_suspend+0x37)
0xc0244665 is in velocity_suspend (drivers/net/via-velocity.c:3399).
3394if(!netif_running(vptr-dev))
3395return 0;
3396
Re: linux-next: Tree for Feb 24
Rafael J. Wysocki wrote:
On Monday, 25 of February 2008, Kevin Winchester wrote:
Rafael J. Wysocki wrote:
On Sunday, 24 of February 2008, Kevin Winchester wrote:
Today was different - I attempted to suspend and resume from the console,
and the machine did not come back up. I found the following in my log -
any help would be appreciated.
Feb 24 13:59:56 alekhine kernel: [ 456.497875] PM: Syncing filesystems
... done.
Feb 24 14:00:20 alekhine kernel: [ 456.507273] Freezing user space
processes ... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510447] Freezing remaining
freezable tasks ... (elapsed 0.00 seconds) done.
Feb 24 14:00:20 alekhine kernel: [ 456.510754] ACPI: Preparing to enter
system sleep state S3
Feb 24 14:00:20 alekhine kernel: [ 456.612370] Suspending console(s)
Feb 24 14:00:20 alekhine kernel: [ 456.616254] sd 3:0:0:0: [sda]
Synchronizing SCSI cache
Feb 24 14:00:20 alekhine kernel: [ 456.616521] sd 3:0:0:0: [sda] Stopping
disk
Feb 24 14:00:20 alekhine kernel: [ 456.618221] ACPI: PCI interrupt for
device :00:11.5 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.630296] ACPI: PCI interrupt for
device :00:10.4 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.641085] ACPI: PCI interrupt for
device :00:10.3 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.651877] ACPI: PCI interrupt for
device :00:10.2 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.662716] ACPI: PCI interrupt for
device :00:10.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.673550] ACPI: PCI interrupt for
device :00:10.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.684385] ACPI: PCI interrupt for
device :00:0f.1 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.695056] ACPI: PCI interrupt for
device :00:0f.0 disabled
Feb 24 14:00:20 alekhine kernel: [ 456.705856] 5 locks held by bash/2929:
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #0:
(buffer-mutex){--..}, at: [c018960c] sysfs_write_file+0x25/0xe3
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #1: (pm_mutex){--..},
at: [c0138c54] enter_state+0xea/0x100
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #2:
(pm_sleep_rwsem){}, at: [c023c4b8] device_suspend+0x25/0x251
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #3:
(data-update_lock#2){--..}, at: [c029cb2b] abituguru_suspend+0x13/0x18
Feb 24 14:00:20 alekhine kernel: [ 456.705856] #4: (vptr-lock){++..},
at: [c0244665] velocity_suspend+0x37/0x302
Feb 24 14:00:20 alekhine kernel: [ 456.705856] irq event stamp: 19374
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last enabled at
(19373): [c0326664] __mutex_unlock_slowpath+0xd5/0xef
Feb 24 14:00:20 alekhine kernel: [ 456.705856] hardirqs last disabled at
(19374): [c0327bca] _spin_lock_irqsave+0xf/0x3c
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last enabled at
(18484): [c011e6ba] __do_softirq+0x99/0x9e
Feb 24 14:00:20 alekhine kernel: [ 456.705856] softirqs last disabled at
(18479): [c0104f15] do_softirq+0x58/0xa8
Feb 24 14:00:20 alekhine kernel: [ 456.705856] Pid: 2929, comm: bash Not
tainted 2.6.25-rc2-next-20080224 #58
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01177c7]
__schedule_bug+0x58/0x5f
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0325b43]
schedule+0x67/0x3b3
Well, could you check what's at schedule+0x67, please?
Is this how I would do this? I tried schedule+0x67, but it just showed me
the beginning of profile_hit.
(gdb) l *(schedule+0x66)
0xc0325b42 is in schedule (kernel/sched.c:3836).
3831 * Test if we are atomic. Since do_exit() needs to call into
3832 * schedule() atomically, we ignore that path for now.
3833 * Otherwise, whine if we are scheduling when we should not be.
3834 */
3835 if (unlikely(in_atomic_preempt_off())
unlikely(!prev-exit_state))
3836 __schedule_bug(prev);
3837
3838 profile_hit(SCHED_PROFILING, __builtin_return_address(0));
3839
3840 schedstat_inc(this_rq(), sched_count);
It appears that we are scheduling when we should not be...
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0121c39] ?
__mod_timer+0x8d/0x98
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326043]
schedule_timeout+0x73/0x91
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c012185c] ?
process_timeout+0x0/0xa
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0326075]
schedule_timeout_uninterruptible+0x14/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0121c54]
msleep+0x10/0x16
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c01e0e51]
pci_set_power_state+0x17f/0x200
Feb 24 14:00:20 alekhine kernel: [ 456.705856] [c0244917]
velocity_suspend+0x2e9/0x302
velocity_suspend() seems to be at fault.
(gdb) l *(velocity_suspend+0x37)
0xc0244665 is in velocity_suspend (drivers/net/via-velocity.c:3399).
3394
Re: 2.6.25-rc2-mm1
Steven Rostedt wrote: > > On Mon, 18 Feb 2008, Andrew Morton wrote: > >>> I don't think I've seen anyone else report this, but if I'm wrong, I'm >>> sure someone will point me to the thread. >> No, I think it's new. >> > >> Looks like an ftrace-vs-lockdep problem. >> > > Is there a .config around to look at? > Sorry, here it is. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sun Feb 17 13:12:53 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set
Re: 2.6.25-rc2-mm1
Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ > > - git-xfs is dropped due to git conflicts > > - git-x86 is dropped due to too many changes to non-x86 code > > - git-perfmon remains dropped due to rejects > > - git-kgdb remains dropped due to rejects > > - Added the slab/slub tree as git-slub.patch (Christoph Lameter) > > I don't think I've seen anyone else report this, but if I'm wrong, I'm sure someone will point me to the thread. This is during boot up, and doesn't seem to have any effect on the running system, that I can tell. [0.090840] [ cut here ] [0.090920] WARNING: at kernel/lockdep.c:2677 check_flags+0x8d/0x12d() [0.090986] Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #49 [0.090986] [] warn_on_slowpath+0x41/0x72 [0.090986] [] ? __lock_acquire+0xb99/0xbb5 [0.090986] [] ? ftrace_record_ip+0x11e/0x17a [0.090986] [] ? mcount_call+0x5/0x9 [0.090986] [] ? check_chain_key+0xe/0x16a [0.090986] [] ? ftrace_record_ip+0x11e/0x17a [0.090986] [] ? debug_locks_off+0x8/0x3c [0.090986] [] ? mcount_call+0x5/0x9 [0.090986] [] ? sub_preempt_count+0xa/0xb0 [0.090986] [] ? _spin_unlock_irqrestore+0x47/0x5d [0.090986] [] ? ftrace_record_ip+0x11e/0x17a [0.090986] [] ? mcount_call+0x5/0x9 [0.090986] [] check_flags+0x8d/0x12d [0.090986] [] lock_acquire+0x36/0x82 [0.090986] [] down_write+0x2d/0x48 [0.090986] [] ? kmem_cache_create+0x21/0x1a7 [0.090986] [] kmem_cache_create+0x21/0x1a7 [0.090986] [] filelock_init+0x23/0x2c [0.090986] [] ? init_once+0x0/0x11 [0.090986] [] kernel_init+0xb6/0x203 [0.090986] [] ? restore_nocheck_notrace+0x0/0xe [0.090986] [] ? kernel_init+0x0/0x203 [0.090986] [] ? kernel_init+0x0/0x203 [0.090986] [] kernel_thread_helper+0x7/0x10 [0.090986] === [0.090986] ---[ end trace 4eaa2a86a8e2da22 ]--- [0.090986] possible reason: unannotated irqs-on. [0.090986] irq event stamp: 1404 [0.090986] hardirqs last enabled at (1403): [] trace_hardirqs_on+0xb/0xd [0.090986] hardirqs last disabled at (1404): [] trace_hardirqs_off+0xb/0xd [0.090986] softirqs last enabled at (1010): [] __do_softirq+0x9e/0xa3 [0.090986] softirqs last disabled at (1003): [] do_softirq+0x5d/0xad -- 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.25-rc2-mm1
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ - git-xfs is dropped due to git conflicts - git-x86 is dropped due to too many changes to non-x86 code - git-perfmon remains dropped due to rejects - git-kgdb remains dropped due to rejects - Added the slab/slub tree as git-slub.patch (Christoph Lameter) I don't think I've seen anyone else report this, but if I'm wrong, I'm sure someone will point me to the thread. This is during boot up, and doesn't seem to have any effect on the running system, that I can tell. [0.090840] [ cut here ] [0.090920] WARNING: at kernel/lockdep.c:2677 check_flags+0x8d/0x12d() [0.090986] Pid: 1, comm: swapper Not tainted 2.6.25-rc2-mm1 #49 [0.090986] [c011b92d] warn_on_slowpath+0x41/0x72 [0.090986] [c0136ff1] ? __lock_acquire+0xb99/0xbb5 [0.090986] [c0140632] ? ftrace_record_ip+0x11e/0x17a [0.090986] [c0102bd0] ? mcount_call+0x5/0x9 [0.090986] [c01344f0] ? check_chain_key+0xe/0x16a [0.090986] [c0140632] ? ftrace_record_ip+0x11e/0x17a [0.090986] [c01dd1a8] ? debug_locks_off+0x8/0x3c [0.090986] [c0102bd0] ? mcount_call+0x5/0x9 [0.090986] [c01182c4] ? sub_preempt_count+0xa/0xb0 [0.090986] [c03453bd] ? _spin_unlock_irqrestore+0x47/0x5d [0.090986] [c0140632] ? ftrace_record_ip+0x11e/0x17a [0.090986] [c0102bd0] ? mcount_call+0x5/0x9 [0.090986] [c0134442] check_flags+0x8d/0x12d [0.090986] [c0137043] lock_acquire+0x36/0x82 [0.090986] [c03440c2] down_write+0x2d/0x48 [0.090986] [c015e91a] ? kmem_cache_create+0x21/0x1a7 [0.090986] [c015e91a] kmem_cache_create+0x21/0x1a7 [0.090986] [c0449642] filelock_init+0x23/0x2c [0.090986] [c016d908] ? init_once+0x0/0x11 [0.090986] [c043d697] kernel_init+0xb6/0x203 [0.090986] [c0102dae] ? restore_nocheck_notrace+0x0/0xe [0.090986] [c043d5e1] ? kernel_init+0x0/0x203 [0.090986] [c043d5e1] ? kernel_init+0x0/0x203 [0.090986] [c01038d3] kernel_thread_helper+0x7/0x10 [0.090986] === [0.090986] ---[ end trace 4eaa2a86a8e2da22 ]--- [0.090986] possible reason: unannotated irqs-on. [0.090986] irq event stamp: 1404 [0.090986] hardirqs last enabled at (1403): [c01360a0] trace_hardirqs_on+0xb/0xd [0.090986] hardirqs last disabled at (1404): [c0134c15] trace_hardirqs_off+0xb/0xd [0.090986] softirqs last enabled at (1010): [c011fc87] __do_softirq+0x9e/0xa3 [0.090986] softirqs last disabled at (1003): [c010508d] do_softirq+0x5d/0xad -- 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.25-rc2-mm1
Steven Rostedt wrote: On Mon, 18 Feb 2008, Andrew Morton wrote: I don't think I've seen anyone else report this, but if I'm wrong, I'm sure someone will point me to the thread. No, I think it's new. Looks like an ftrace-vs-lockdep problem. Is there a .config around to look at? Sorry, here it is. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc2-mm1 # Sun Feb 17 13:12:53 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set
Latency issues with x86.git
Hi Ingo, I have encountered (a handful of times in the past few months) some real interactivity problems on my system. Moving the mouse or typing a key on the keyboard takes around a second to show any response. Once I perform a reboot, the problem is gone again. I am currently running x86.git mm branch, but I switch between that branch, mainline git, and mm kernels, so I cannot guarantee on which trees I have or have not seen the problem. It seems to have started around the time that CFS came into being, but it might be something completely unrelated. When it happened this evening, I ran the cfs-debug-info.sh script to which you had referred me in another thread. I'm not sure if this helps to debug the problem, but it was all I could think to try. I have LatencyTOP in my kernel, so I guess I could try the userspace tool as well the next time. The output of the script is at: http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.02.13-20.56.38 Unfortunately, I cannot reproduce the problem intentionally - it only happens once a month or so. If there is any other info you need, please let me know, or any suggestions for what to try the next time. Thanks, -- Kevin Winchester -- 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/
Latency issues with x86.git
Hi Ingo, I have encountered (a handful of times in the past few months) some real interactivity problems on my system. Moving the mouse or typing a key on the keyboard takes around a second to show any response. Once I perform a reboot, the problem is gone again. I am currently running x86.git mm branch, but I switch between that branch, mainline git, and mm kernels, so I cannot guarantee on which trees I have or have not seen the problem. It seems to have started around the time that CFS came into being, but it might be something completely unrelated. When it happened this evening, I ran the cfs-debug-info.sh script to which you had referred me in another thread. I'm not sure if this helps to debug the problem, but it was all I could think to try. I have LatencyTOP in my kernel, so I guess I could try the userspace tool as well the next time. The output of the script is at: http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.02.13-20.56.38 Unfortunately, I cannot reproduce the problem intentionally - it only happens once a month or so. If there is any other info you need, please let me know, or any suggestions for what to try the next time. Thanks, -- Kevin Winchester -- 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: git-x86 mm branch compile error
Kevin Winchester wrote:
> CC arch/x86/mm/pageattr.o
> arch/x86/mm/pageattr.c: In function ‘change_page_attr_set_clr’:
> arch/x86/mm/pageattr.c:778: error: incompatible type for argument 1 of
> ‘cpa_check_alias’
> make[1]: *** [arch/x86/mm/pageattr.o] Error 1
> make: *** [arch/x86/mm] Error 2
>
> at tip 5248bbad9c72dd576aa8f3b44b5a959a7cae6ce1 x86: make
> DEBUG_PAGEALLOC & HIBERNATE work
>
>
>
I assume the following is an acceptable fix (it will be completely
whitespace damaged due to thunderbird, but I think you get the idea)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index cf91149..76a3de5 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -729,7 +729,7 @@ cpa_check_alias(struct cpa_data *cpa, unsigned long
addr, int numpages)
#else
static int
-cpa_check_alias(struct cpa_data cpa, unsigned long addr, int numpages)
+cpa_check_alias(struct cpa_data *cpa, unsigned long addr, int numpages)
{
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
git-x86 mm branch compile error
CC arch/x86/mm/pageattr.o arch/x86/mm/pageattr.c: In function ‘change_page_attr_set_clr’: arch/x86/mm/pageattr.c:778: error: incompatible type for argument 1 of ‘cpa_check_alias’ make[1]: *** [arch/x86/mm/pageattr.o] Error 1 make: *** [arch/x86/mm] Error 2 at tip 5248bbad9c72dd576aa8f3b44b5a959a7cae6ce1 x86: make DEBUG_PAGEALLOC & HIBERNATE work -- 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: git-x86 mm branch compile error
Kevin Winchester wrote:
CC arch/x86/mm/pageattr.o
arch/x86/mm/pageattr.c: In function ‘change_page_attr_set_clr’:
arch/x86/mm/pageattr.c:778: error: incompatible type for argument 1 of
‘cpa_check_alias’
make[1]: *** [arch/x86/mm/pageattr.o] Error 1
make: *** [arch/x86/mm] Error 2
at tip 5248bbad9c72dd576aa8f3b44b5a959a7cae6ce1 x86: make
DEBUG_PAGEALLOC HIBERNATE work
I assume the following is an acceptable fix (it will be completely
whitespace damaged due to thunderbird, but I think you get the idea)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index cf91149..76a3de5 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -729,7 +729,7 @@ cpa_check_alias(struct cpa_data *cpa, unsigned long
addr, int numpages)
#else
static int
-cpa_check_alias(struct cpa_data cpa, unsigned long addr, int numpages)
+cpa_check_alias(struct cpa_data *cpa, unsigned long addr, int numpages)
{
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
git-x86 mm branch compile error
CC arch/x86/mm/pageattr.o arch/x86/mm/pageattr.c: In function ‘change_page_attr_set_clr’: arch/x86/mm/pageattr.c:778: error: incompatible type for argument 1 of ‘cpa_check_alias’ make[1]: *** [arch/x86/mm/pageattr.o] Error 1 make: *** [arch/x86/mm] Error 2 at tip 5248bbad9c72dd576aa8f3b44b5a959a7cae6ce1 x86: make DEBUG_PAGEALLOC HIBERNATE work -- 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/
v2.6.24-mm1 lockdep.c warning
Found this in my dmesg: [ 10.671500] [ cut here ] [ 10.671500] WARNING: at kernel/lockdep.c:2037 trace_hardirqs_on+0xba/0x113() [ 10.671500] Pid: 0, comm: swapper Not tainted 2.6.24-mm1 #2 [ 10.671500] [] warn_on_slowpath+0x3c/0x4c [ 10.671500] [] ? check_usage_forwards+0x19/0x3b [ 10.671500] [] ? mark_lock+0x1ab/0x3ae [ 10.671500] [] ? ata_hsm_qc_complete+0xbc/0xc2 [ 10.671500] [] ? _spin_unlock_irq+0x22/0x42 [ 10.671500] [] trace_hardirqs_on+0xba/0x113 [ 10.671500] [] _spin_unlock_irq+0x22/0x42 [ 10.671500] [] hpet_rtc_interrupt+0xe8/0x299 [ 10.671500] [] handle_IRQ_event+0x1a/0x46 [ 10.671500] [] handle_edge_irq+0xa6/0x102 [ 10.671500] [] ? handle_edge_irq+0x0/0x102 [ 10.671500] [] do_IRQ+0x87/0xb0 [ 10.671500] [] common_interrupt+0x2e/0x34 [ 10.671500] [] ? default_idle+0x45/0x72 [ 10.671500] [] ? default_idle+0x0/0x72 [ 10.671500] [] cpu_idle+0x73/0xa3 [ 10.671500] [] rest_init+0x61/0x63 [ 10.671500] === [ 10.671500] ---[ end trace e5cdd42f557be0f0 ]--- I have no idea what went on here - I'll start tracing through the call stack to see if I can figure anything out... config below -- Kevin Winchester # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Mon Feb 4 20:18:12 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set #
v2.6.24-mm1 lockdep.c warning
Found this in my dmesg: [ 10.671500] [ cut here ] [ 10.671500] WARNING: at kernel/lockdep.c:2037 trace_hardirqs_on+0xba/0x113() [ 10.671500] Pid: 0, comm: swapper Not tainted 2.6.24-mm1 #2 [ 10.671500] [c011a54f] warn_on_slowpath+0x3c/0x4c [ 10.671500] [c01335a0] ? check_usage_forwards+0x19/0x3b [ 10.671500] [c013376d] ? mark_lock+0x1ab/0x3ae [ 10.671500] [c026c84d] ? ata_hsm_qc_complete+0xbc/0xc2 [ 10.671500] [c03495eb] ? _spin_unlock_irq+0x22/0x42 [ 10.671500] [c0133b0e] trace_hardirqs_on+0xba/0x113 [ 10.671500] [c03495eb] _spin_unlock_irq+0x22/0x42 [ 10.671500] [c011103d] hpet_rtc_interrupt+0xe8/0x299 [ 10.671500] [c0139547] handle_IRQ_event+0x1a/0x46 [ 10.671500] [c013a359] handle_edge_irq+0xa6/0x102 [ 10.671500] [c013a2b3] ? handle_edge_irq+0x0/0x102 [ 10.671500] [c0106070] do_IRQ+0x87/0xb0 [ 10.671500] [c010470a] common_interrupt+0x2e/0x34 [ 10.671500] [c0102974] ? default_idle+0x45/0x72 [ 10.671500] [c010292f] ? default_idle+0x0/0x72 [ 10.671500] [c01028ff] cpu_idle+0x73/0xa3 [ 10.671500] [c033fcd1] rest_init+0x61/0x63 [ 10.671500] === [ 10.671500] ---[ end trace e5cdd42f557be0f0 ]--- I have no idea what went on here - I'll start tracing through the call stack to see if I can figure anything out... config below -- Kevin Winchester # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-mm1 # Mon Feb 4 20:18:12 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set
Re: Latest -git ioremap error
Ingo Molnar wrote:
> * Kevin Winchester <[EMAIL PROTECTED]> wrote:
>
>>> x86: fix ioremap RAM check
>>>
>>> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
>>> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>> Lucky first try - reverting this commit fixes the problem for me. Any
>> ideas?
>
> Could you check the patch below - does that too fix the problem for you?
>
Yes, the patch below fixes the problem. I guess that makes it a:
Tested-by: Kevin Winchester <[EMAIL PROTECTED]>
> Ingo
>
> ->
> Subject: x86: relax RAM check in ioremap()
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> Kevin Winchester reported the loss of direct rendering, due to:
>
> [0.588184] agpgart: Detected AGP bridge 0
> [0.588184] agpgart: unable to get memory for graphics translation table.
> [0.588184] agpgart: agp_backend_initialize() failed.
> [0.588207] agpgart-amd64: probe of :00:00.0 failed with error -12
>
> and bisected it down to:
>
>> commit 266b9f8727976769e2ed2dad77ac9295f37e321e
>> Author: Thomas Gleixner <[EMAIL PROTECTED]>
>> Date: Wed Jan 30 13:34:06 2008 +0100
>>
>> x86: fix ioremap RAM check
>
> this check was too strict and caused an ioremap() failure.
>
> the problem is due to the somewhat unclean way of how the GART code
> reserves a memory range for its aperture, and how it utilizes it
> later on.
>
> Allow RAM pages to be ioremap()-ed too, as long as they are reserved.
>
> Bisected-by: Kevin Winchester <[EMAIL PROTECTED]>
> Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> arch/x86/mm/ioremap.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Index: linux-x86.q/arch/x86/mm/ioremap.c
> ===
> --- linux-x86.q.orig/arch/x86/mm/ioremap.c
> +++ linux-x86.q/arch/x86/mm/ioremap.c
> @@ -116,7 +116,7 @@ static void __iomem *__ioremap(unsigned
> {
> void __iomem *addr;
> struct vm_struct *area;
> - unsigned long offset, last_addr;
> + unsigned long pfn, offset, last_addr;
> pgprot_t prot;
>
> /* Don't allow wraparound or zero size */
> @@ -133,9 +133,9 @@ static void __iomem *__ioremap(unsigned
> /*
>* Don't allow anybody to remap normal RAM that we're using..
>*/
> - for (offset = phys_addr >> PAGE_SHIFT; offset < max_pfn_mapped &&
> - (offset << PAGE_SHIFT) < last_addr; offset++) {
> - if (page_is_ram(offset))
> + for (pfn = phys_addr >> PAGE_SHIFT; pfn < max_pfn_mapped &&
> + (pfn << PAGE_SHIFT) < last_addr; pfn++) {
> + if (pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)))
> return NULL;
> }
>
--
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: Latest -git ioremap error
Kevin Winchester wrote:
> Hi Thomas, Ingo,
>
> I noticed that my direct rendering is no longer working, with the
> following in my dmesg:
>
> [0.588184] agpgart: Detected AGP bridge 0
> [0.588184] agpgart: unable to get memory for graphics translation table.
> [0.588184] agpgart: agp_backend_initialize() failed.
> [0.588207] agpgart-amd64: probe of :00:00.0 failed with error -12
>
> Tracking down the error somewhat with added printks leads to the
> following block in __ioremap():
>
>
> /*
> * Don't allow anybody to remap normal RAM that we're using..
> */
> for (offset = phys_addr >> PAGE_SHIFT; offset < max_pfn_mapped &&
> (offset << PAGE_SHIFT) < last_addr; offset++) {
> if (page_is_ram(offset))
> return NULL;
> }
>
>
> And git blame lead me to the following commit:
>
> commit 266b9f8727976769e2ed2dad77ac9295f37e321e
> Author: Thomas Gleixner <[EMAIL PROTECTED]>
> Date: Wed Jan 30 13:34:06 2008 +0100
>
> x86: fix ioremap RAM check
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
>
Lucky first try - reverting this commit fixes the problem for me. Any
ideas?
--
Kevin Winchester
--
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: Latest -git ioremap error
Kevin Winchester wrote:
Hi Thomas, Ingo,
I noticed that my direct rendering is no longer working, with the
following in my dmesg:
[0.588184] agpgart: Detected AGP bridge 0
[0.588184] agpgart: unable to get memory for graphics translation table.
[0.588184] agpgart: agp_backend_initialize() failed.
[0.588207] agpgart-amd64: probe of :00:00.0 failed with error -12
Tracking down the error somewhat with added printks leads to the
following block in __ioremap():
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
for (offset = phys_addr PAGE_SHIFT; offset max_pfn_mapped
(offset PAGE_SHIFT) last_addr; offset++) {
if (page_is_ram(offset))
return NULL;
}
And git blame lead me to the following commit:
commit 266b9f8727976769e2ed2dad77ac9295f37e321e
Author: Thomas Gleixner [EMAIL PROTECTED]
Date: Wed Jan 30 13:34:06 2008 +0100
x86: fix ioremap RAM check
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Lucky first try - reverting this commit fixes the problem for me. Any
ideas?
--
Kevin Winchester
--
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: Latest -git ioremap error
Ingo Molnar wrote:
* Kevin Winchester [EMAIL PROTECTED] wrote:
x86: fix ioremap RAM check
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Lucky first try - reverting this commit fixes the problem for me. Any
ideas?
Could you check the patch below - does that too fix the problem for you?
Yes, the patch below fixes the problem. I guess that makes it a:
Tested-by: Kevin Winchester [EMAIL PROTECTED]
Ingo
-
Subject: x86: relax RAM check in ioremap()
From: Ingo Molnar [EMAIL PROTECTED]
Kevin Winchester reported the loss of direct rendering, due to:
[0.588184] agpgart: Detected AGP bridge 0
[0.588184] agpgart: unable to get memory for graphics translation table.
[0.588184] agpgart: agp_backend_initialize() failed.
[0.588207] agpgart-amd64: probe of :00:00.0 failed with error -12
and bisected it down to:
commit 266b9f8727976769e2ed2dad77ac9295f37e321e
Author: Thomas Gleixner [EMAIL PROTECTED]
Date: Wed Jan 30 13:34:06 2008 +0100
x86: fix ioremap RAM check
this check was too strict and caused an ioremap() failure.
the problem is due to the somewhat unclean way of how the GART code
reserves a memory range for its aperture, and how it utilizes it
later on.
Allow RAM pages to be ioremap()-ed too, as long as they are reserved.
Bisected-by: Kevin Winchester [EMAIL PROTECTED]
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
arch/x86/mm/ioremap.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-x86.q/arch/x86/mm/ioremap.c
===
--- linux-x86.q.orig/arch/x86/mm/ioremap.c
+++ linux-x86.q/arch/x86/mm/ioremap.c
@@ -116,7 +116,7 @@ static void __iomem *__ioremap(unsigned
{
void __iomem *addr;
struct vm_struct *area;
- unsigned long offset, last_addr;
+ unsigned long pfn, offset, last_addr;
pgprot_t prot;
/* Don't allow wraparound or zero size */
@@ -133,9 +133,9 @@ static void __iomem *__ioremap(unsigned
/*
* Don't allow anybody to remap normal RAM that we're using..
*/
- for (offset = phys_addr PAGE_SHIFT; offset max_pfn_mapped
- (offset PAGE_SHIFT) last_addr; offset++) {
- if (page_is_ram(offset))
+ for (pfn = phys_addr PAGE_SHIFT; pfn max_pfn_mapped
+ (pfn PAGE_SHIFT) last_addr; pfn++) {
+ if (pfn_valid(pfn) !PageReserved(pfn_to_page(pfn)))
return NULL;
}
--
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/
Automated Kernel Testing
Hi Ingo & Andrew, Since you both seem to be quite interested in the number of kernel testers and the reporting of bugs, I figured I would bounce this idea off of you... As a part-time kernel tester, I find it interesting to see that Ingo has tools that are able to automatically configure/build/boot/test kernels, and it has given me the following ideas: - For people like me, it would be great if there were a downloadable collection of tools for performing similar testing on my box here whenever I'm not using it. - The tools could build a kernel, boot it, run some standard tests, and report any problems automatically. - The kernel oops web site and auto-submit tool seems like it would be a very good companion to the testing tools (if you don't already have them integrated). - In the future, I would expect that a [EMAIL PROTECTED] testing package could be integrated into distribution repositories so that users could do automatic testing (build testing for people scared about data loss, and boot testing as well for those not worried). I would be happy to help out with the work in developing this set of tools (as far as my limited skills allow), but I have a feeling that you already have most of it in some form. I think the final piece is just the integration and marketing so that the barrier to kernel testing gets lowered considerably. Does this seem like a reasonable idea, or is it something that you already had in mind (that it just took me longer to see)? -- Kevin Winchester -- 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/
Automated Kernel Testing
Hi Ingo Andrew, Since you both seem to be quite interested in the number of kernel testers and the reporting of bugs, I figured I would bounce this idea off of you... As a part-time kernel tester, I find it interesting to see that Ingo has tools that are able to automatically configure/build/boot/test kernels, and it has given me the following ideas: - For people like me, it would be great if there were a downloadable collection of tools for performing similar testing on my box here whenever I'm not using it. - The tools could build a kernel, boot it, run some standard tests, and report any problems automatically. - The kernel oops web site and auto-submit tool seems like it would be a very good companion to the testing tools (if you don't already have them integrated). - In the future, I would expect that a [EMAIL PROTECTED] testing package could be integrated into distribution repositories so that users could do automatic testing (build testing for people scared about data loss, and boot testing as well for those not worried). I would be happy to help out with the work in developing this set of tools (as far as my limited skills allow), but I have a feeling that you already have most of it in some form. I think the final piece is just the integration and marketing so that the barrier to kernel testing gets lowered considerably. Does this seem like a reasonable idea, or is it something that you already had in mind (that it just took me longer to see)? -- Kevin Winchester -- 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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:42:44 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm, perhaps it's due to the xtime lock dependency:
> >
> > do {
> > seq = read_seqbegin(_lock);
> > getnstimeofday(ts);
> > tomono = wall_to_monotonic;
> >
> > } while (read_seqretry(_lock, seq));
> >
> > perhaps your system somehow generates a printk from within an
> > xtime_lock locked section?
>
> i _bet_ it's these printks that cause your lockup:
>
> [ 10.313437] Marking TSC unstable due to: cpufreq changes.
> [ 10.313437] Time: hpet clocksource has been installed.
> [ 10.424431] Clocksource tsc unstable (delta = -121609771 ns)
>
> as these are done with the xtime lock held.
>
Yes, disabling cpufreq (in my .config since, sadly, there is no command
line option to disable it) fixes the problem.
--
Kevin Winchester <[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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:42:44 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm, perhaps it's due to the xtime lock dependency:
> >
> > do {
> > seq = read_seqbegin(_lock);
> > getnstimeofday(ts);
> > tomono = wall_to_monotonic;
> >
> > } while (read_seqretry(_lock, seq));
> >
> > perhaps your system somehow generates a printk from within an
> > xtime_lock locked section?
>
> i _bet_ it's these printks that cause your lockup:
>
> [ 10.313437] Marking TSC unstable due to: cpufreq changes.
> [ 10.313437] Time: hpet clocksource has been installed.
> [ 10.424431] Clocksource tsc unstable (delta = -121609771 ns)
>
> as these are done with the xtime lock held.
>
Ok, I'll try disabling cpufreq to see if that prevents the lockup. If
that is the problem, what is the fix? Just to keep the path reverted?
--
Kevin Winchester <[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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:37:02 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Kevin Winchester <[EMAIL PROTECTED]> wrote: > > > Sure, the result of the script is at > > > > http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.01.27-08.13.28 > > it seems you've got hpet active by default: > > /sys/devices/system/clocksource/clocksource0/current_clocksource: > hpet > /sys/devices/system/clocksource/clocksource0/available_clocksource: > hpet acpi_pm pit jiffies tsc > > do you get a similar lockup if you use acpi_pm? You can do that either > by disabling the HPET options in your .config, or by doing this prior > starting up X: > > echo acpi_pm > > /sys/devices/system/clocksource/clocksource0/current_clocksource > Since X was being autostarted when the computer booted, I just removed "hpet=force" from my command line instead. The result was that the lockup happened earlier, so that it was before X was being started. So I guess X is not the culprit. -- Kevin Winchester <[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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:35:14 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Kevin Winchester <[EMAIL PROTECTED]> wrote: > > > although it is not complete. For some reason (xubuntu, probably) dash > > is my default shell and it does not like the for loop at line 69 of > > that script: > > > > for ((i=0; i<5; i++)); do > > echo "-- sched_debug #$i: --" >> $FILE > > date>> $FILE > > cat /proc/sched_debug >> $FILE 2>/dev/null > > sleep 1 > > done > > > > Not being a shell scripter, I have no idea how to port that to dash. > > oops, stick this to the top of the script: > > #!/bin/bash > > as that loop is a bashism. (I've updated the script on my site as well.) > > Ingo Here is the updated script run without the missing info: http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.01.27-19.04.50 -- Kevin Winchester <[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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:35:14 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Kevin Winchester [EMAIL PROTECTED] wrote: although it is not complete. For some reason (xubuntu, probably) dash is my default shell and it does not like the for loop at line 69 of that script: for ((i=0; i5; i++)); do echo -- sched_debug #$i: --$FILE date $FILE cat /proc/sched_debug$FILE 2/dev/null sleep 1 done Not being a shell scripter, I have no idea how to port that to dash. oops, stick this to the top of the script: #!/bin/bash as that loop is a bashism. (I've updated the script on my site as well.) Ingo Here is the updated script run without the missing info: http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.01.27-19.04.50 -- Kevin Winchester [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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:37:02 +0100 Ingo Molnar [EMAIL PROTECTED] wrote: * Kevin Winchester [EMAIL PROTECTED] wrote: Sure, the result of the script is at http://personal.nbnet.nb.ca/kwin/cfs-debug-info-2008.01.27-08.13.28 it seems you've got hpet active by default: /sys/devices/system/clocksource/clocksource0/current_clocksource: hpet /sys/devices/system/clocksource/clocksource0/available_clocksource: hpet acpi_pm pit jiffies tsc do you get a similar lockup if you use acpi_pm? You can do that either by disabling the HPET options in your .config, or by doing this prior starting up X: echo acpi_pm /sys/devices/system/clocksource/clocksource0/current_clocksource Since X was being autostarted when the computer booted, I just removed hpet=force from my command line instead. The result was that the lockup happened earlier, so that it was before X was being started. So I guess X is not the culprit. -- Kevin Winchester [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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:42:44 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm, perhaps it's due to the xtime lock dependency:
do {
seq = read_seqbegin(xtime_lock);
getnstimeofday(ts);
tomono = wall_to_monotonic;
} while (read_seqretry(xtime_lock, seq));
perhaps your system somehow generates a printk from within an
xtime_lock locked section?
i _bet_ it's these printks that cause your lockup:
[ 10.313437] Marking TSC unstable due to: cpufreq changes.
[ 10.313437] Time: hpet clocksource has been installed.
[ 10.424431] Clocksource tsc unstable (delta = -121609771 ns)
as these are done with the xtime lock held.
Ok, I'll try disabling cpufreq to see if that prevents the lockup. If
that is the problem, what is the fix? Just to keep the path reverted?
--
Kevin Winchester [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: X fails to start with latest Linus git
On Sun, 27 Jan 2008 13:42:44 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
hm, perhaps it's due to the xtime lock dependency:
do {
seq = read_seqbegin(xtime_lock);
getnstimeofday(ts);
tomono = wall_to_monotonic;
} while (read_seqretry(xtime_lock, seq));
perhaps your system somehow generates a printk from within an
xtime_lock locked section?
i _bet_ it's these printks that cause your lockup:
[ 10.313437] Marking TSC unstable due to: cpufreq changes.
[ 10.313437] Time: hpet clocksource has been installed.
[ 10.424431] Clocksource tsc unstable (delta = -121609771 ns)
as these are done with the xtime lock held.
Yes, disabling cpufreq (in my .config since, sadly, there is no command
line option to disable it) fixes the problem.
--
Kevin Winchester [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: X fails to start with latest Linus git
Kevin Winchester wrote: > Hi Ingo, > > Starting X (autostarted with GDM) manages to lock up my system > (requiring a hard reset) after the first few tree merges of the window, > and bisection shows: > > - > > 19ef9309273d26cb005cb23e6a370353dca91099 is first bad commit > commit 19ef9309273d26cb005cb23e6a370353dca91099 > Author: Ingo Molnar <[EMAIL PROTECTED]> > Date: Fri Jan 25 21:08:34 2008 +0100 > > printk: use ktime_get() > > printk timestamps: use ktime_get(). > > Some platforms have a functioning clocksource function only after > they are done with early bootup, so delay this until out of > SYSTEM_BOOTING state. > > it's also inherently safe now, as any bugs in this area will be > caught by the printk recursion checks. > > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > > - > > as the first bad commit. I have no idea why that would cause problems, > so it could also be some timing-related problem that just happened to > bisect to this patch. > > I will try advancing to the head of Linus' tree and then reverting this > patch to make sure it fixes the problem, but I figured I'd send this > first to see if it is obvious to anyone. > Yes, with this as my "git log" : commit 1814180093994543e8fbfd8d91f383081a9bc283 Author: Kevin Winchester <[EMAIL PROTECTED](none)> Date: Sat Jan 26 20:21:44 2008 -0400 Revert "printk: use ktime_get()" This reverts commit 19ef9309273d26cb005cb23e6a370353dca91099. commit 9b73e76f3cf63379dcf45fcd4f112f5812418d0a Merge: 50d9a12... 23c3e29... Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Fri Jan 25 17:19:08 2008 -0800 Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (200 commits) [SCSI] usbstorage: use last_sector_bug flag universally [SCSI] libsas: abstract STP task status into a function [SCSI] ultrastor: clean up inline asm warnings [SCSI] aic7xxx: fix firmware build [SCSI] aacraid: fib context lock for management ioctls [SCSI] ch: remove forward declarations [SCSI] ch: fix device minor number management bug [SCSI] ch: handle class_device_create failure properly [SCSI] NCR5380: fix section mismatch [SCSI] sg: fix /proc/scsi/sg/devices when no SCSI devices [SCSI] IB/iSER: add logical unit reset support [SCSI] don't use __GFP_DMA for sense buffers if not required [SCSI] use dynamically allocated sense buffer [SCSI] scsi.h: add macro for enclosure bit of inquiry data [SCSI] sd: add fix for devices with last sector access problems [SCSI] fix pcmcia compile problem [SCSI] aacraid: add Voodoo Lite class of cards. [SCSI] aacraid: add new driver features flags [SCSI] qla2xxx: Update version number to 8.02.00-k7. [SCSI] qla2xxx: Issue correct MBC_INITIALIZE_FIRMWARE command. ... - The machine boots normally, but without that revert, X locks up. Does that make sense to anyone? -- Kevin Winchester -- 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/
X fails to start with latest Linus git
Hi Ingo, Starting X (autostarted with GDM) manages to lock up my system (requiring a hard reset) after the first few tree merges of the window, and bisection shows: - 19ef9309273d26cb005cb23e6a370353dca91099 is first bad commit commit 19ef9309273d26cb005cb23e6a370353dca91099 Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Fri Jan 25 21:08:34 2008 +0100 printk: use ktime_get() printk timestamps: use ktime_get(). Some platforms have a functioning clocksource function only after they are done with early bootup, so delay this until out of SYSTEM_BOOTING state. it's also inherently safe now, as any bugs in this area will be caught by the printk recursion checks. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> - as the first bad commit. I have no idea why that would cause problems, so it could also be some timing-related problem that just happened to bisect to this patch. I will try advancing to the head of Linus' tree and then reverting this patch to make sure it fixes the problem, but I figured I'd send this first to see if it is obvious to anyone. -- Kevin Winchester -- 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/
X fails to start with latest Linus git
Hi Ingo, Starting X (autostarted with GDM) manages to lock up my system (requiring a hard reset) after the first few tree merges of the window, and bisection shows: - 19ef9309273d26cb005cb23e6a370353dca91099 is first bad commit commit 19ef9309273d26cb005cb23e6a370353dca91099 Author: Ingo Molnar [EMAIL PROTECTED] Date: Fri Jan 25 21:08:34 2008 +0100 printk: use ktime_get() printk timestamps: use ktime_get(). Some platforms have a functioning clocksource function only after they are done with early bootup, so delay this until out of SYSTEM_BOOTING state. it's also inherently safe now, as any bugs in this area will be caught by the printk recursion checks. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] - as the first bad commit. I have no idea why that would cause problems, so it could also be some timing-related problem that just happened to bisect to this patch. I will try advancing to the head of Linus' tree and then reverting this patch to make sure it fixes the problem, but I figured I'd send this first to see if it is obvious to anyone. -- Kevin Winchester -- 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: X fails to start with latest Linus git
Kevin Winchester wrote: Hi Ingo, Starting X (autostarted with GDM) manages to lock up my system (requiring a hard reset) after the first few tree merges of the window, and bisection shows: - 19ef9309273d26cb005cb23e6a370353dca91099 is first bad commit commit 19ef9309273d26cb005cb23e6a370353dca91099 Author: Ingo Molnar [EMAIL PROTECTED] Date: Fri Jan 25 21:08:34 2008 +0100 printk: use ktime_get() printk timestamps: use ktime_get(). Some platforms have a functioning clocksource function only after they are done with early bootup, so delay this until out of SYSTEM_BOOTING state. it's also inherently safe now, as any bugs in this area will be caught by the printk recursion checks. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] - as the first bad commit. I have no idea why that would cause problems, so it could also be some timing-related problem that just happened to bisect to this patch. I will try advancing to the head of Linus' tree and then reverting this patch to make sure it fixes the problem, but I figured I'd send this first to see if it is obvious to anyone. Yes, with this as my git log : commit 1814180093994543e8fbfd8d91f383081a9bc283 Author: Kevin Winchester [EMAIL PROTECTED](none) Date: Sat Jan 26 20:21:44 2008 -0400 Revert printk: use ktime_get() This reverts commit 19ef9309273d26cb005cb23e6a370353dca91099. commit 9b73e76f3cf63379dcf45fcd4f112f5812418d0a Merge: 50d9a12... 23c3e29... Author: Linus Torvalds [EMAIL PROTECTED] Date: Fri Jan 25 17:19:08 2008 -0800 Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6 * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (200 commits) [SCSI] usbstorage: use last_sector_bug flag universally [SCSI] libsas: abstract STP task status into a function [SCSI] ultrastor: clean up inline asm warnings [SCSI] aic7xxx: fix firmware build [SCSI] aacraid: fib context lock for management ioctls [SCSI] ch: remove forward declarations [SCSI] ch: fix device minor number management bug [SCSI] ch: handle class_device_create failure properly [SCSI] NCR5380: fix section mismatch [SCSI] sg: fix /proc/scsi/sg/devices when no SCSI devices [SCSI] IB/iSER: add logical unit reset support [SCSI] don't use __GFP_DMA for sense buffers if not required [SCSI] use dynamically allocated sense buffer [SCSI] scsi.h: add macro for enclosure bit of inquiry data [SCSI] sd: add fix for devices with last sector access problems [SCSI] fix pcmcia compile problem [SCSI] aacraid: add Voodoo Lite class of cards. [SCSI] aacraid: add new driver features flags [SCSI] qla2xxx: Update version number to 8.02.00-k7. [SCSI] qla2xxx: Issue correct MBC_INITIALIZE_FIRMWARE command. ... - The machine boots normally, but without that revert, X locks up. Does that make sense to anyone? -- Kevin Winchester -- 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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Kevin Winchester wrote:
> > H. Peter Anvin wrote:
> >> Kevin Winchester wrote:
> >>> My first time building and booting the mm branch of x86.git was pretty
> >>> successful. The only error I noticed was the following in my dmesg:
> >>>
> >>> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
> >>>
> >>> I'm not sure exactly how to debug this. I could bisect, but there seems
> >>> to be some useful debug information in there, so there might be
> >>> something better to try first.
> >>>
> >> That's a userspace IP; it implies the userspace hwclock binary did
> >> something bad, or the kernel didn't permit it to do something it should
> >> have. The best thing to do would probably to strace hwclock and see
> >> what it did when it died.
> >>
> >
> > Unfortunately, but the time I can get a chance to run hwclock, the
> > problem seems to have fixed itself. I tried booting into single user
> > mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
> >
>
> The other thing you can do is to download the debug information and
> source code for hwclock from your particular distro, and find out
> exactly what operation inside the hwclock binary is triggering the segfault.
>
> The only other option is to bisect.
>
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
>From include/asm-x86/bitops.h:
static inline void clear_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX "btr %1,%0"
: ADDR
: "Ir" (nr));
}
static inline void __clear_bit(int nr, volatile void *addr)
{
asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
}
so it looks like we removed a lock prefix for the 64-bit case. Was that
intentional? Since I'm building for 32-bit, I'm not sure why I was affected,
so maybe my problem is different. Ingo, didn't you have a script somewhere to
test the before and after of unification patches (or am I remembering something
else)?
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8b4a8de..91a1795 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -10,7 +10,7 @@ CFLAGS_vsyscall_64.o := $(PROFILING) -g0
obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
obj-y += traps_$(BITS).o irq_$(BITS).o
-obj-y += time_$(BITS).o ioport_$(BITS).o ldt.o
+obj-y += time_$(BITS).o ioport.o ldt.o
obj-y += setup_$(BITS).o i8259_$(BITS).o
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
new file mode 100644
index 000..e723ff3
--- /dev/null
+++ b/arch/x86/kernel/ioport.c
@@ -0,0 +1,150 @@
+/*
+ * This contains the io-permission bitmap code - written by obz, with changes
+ * by Linus. 32/64 bits code unification by Miguel Botón.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
+static void set_bitmap(unsigned long *bitmap, unsigned int base,
+ unsigned int extent, int new_value)
+{
+ unsigned int i;
+
+ for (i = base; i < base + extent; i++) {
+ if (new_value)
+ __set_bit(i, bitmap);
+ else
+ __clear_bit(i, bitmap);
+ }
+}
+
+/*
+ * this changes the io permissions bitmap in the current task.
+ */
+asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+ struct thread_struct * t = >thread;
+ struct tss_struct * tss;
+ unsigned int i, max_long, bytes, bytes_updated;
+
+ if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
+ return -EINVAL;
+ if (turn_on && !capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ /*
+
Re: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Kevin Winchester wrote:
> > H. Peter Anvin wrote:
> >> Kevin Winchester wrote:
> >>> My first time building and booting the mm branch of x86.git was pretty
> >>> successful. The only error I noticed was the following in my dmesg:
> >>>
> >>> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
> >>>
> >>> I'm not sure exactly how to debug this. I could bisect, but there seems
> >>> to be some useful debug information in there, so there might be
> >>> something better to try first.
> >>>
> >> That's a userspace IP; it implies the userspace hwclock binary did
> >> something bad, or the kernel didn't permit it to do something it should
> >> have. The best thing to do would probably to strace hwclock and see
> >> what it did when it died.
> >>
> >
> > Unfortunately, but the time I can get a chance to run hwclock, the
> > problem seems to have fixed itself. I tried booting into single user
> > mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
> >
>
> The other thing you can do is to download the debug information and
> source code for hwclock from your particular distro, and find out
> exactly what operation inside the hwclock binary is triggering the segfault.
>
> The only other option is to bisect.
>
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
I'll take a look at the unification and see if I can see anything obvious.
--
Kevin Winchester <[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: hwclock failure in x86.git
H. Peter Anvin wrote: > Kevin Winchester wrote: >> My first time building and booting the mm branch of x86.git was pretty >> successful. The only error I noticed was the following in my dmesg: >> >> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 >> >> I'm not sure exactly how to debug this. I could bisect, but there seems >> to be some useful debug information in there, so there might be >> something better to try first. >> > > That's a userspace IP; it implies the userspace hwclock binary did > something bad, or the kernel didn't permit it to do something it should > have. The best thing to do would probably to strace hwclock and see > what it did when it died. > Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. A few other facts: - This is an Athlon64 box running X83_32 - I use hpet=force for the Via chipset - A little more of the demsg is: [ 17.511262] rtc_cmos 00:05: setting system clock to 2008-01-10 23:44:16 UTC (128656) [ 17.545948] EXT3-fs: mounted filesystem with ordered data mode. [ 17.545986] VFS: Mounted root (ext3 filesystem) readonly. [ 17.546142] Freeing unused kernel memory: 144k freed [ 17.546260] kjournald starting. Commit interval 5 seconds [ 21.861249] hwclock[622] general protection ip:804b226 sp:bfd98480 error:0 [ 22.416442] Velocity is AUTO mode [ 23.093416] Adding 1502036k swap on /dev/sda5. Priority:-1 extents:1 across:1502036k [ 23.416756] EXT3 FS on sda1, internal journal [ 24.009669] kjournald starting. Commit interval 5 seconds [ 24.009889] EXT3 FS on sda6, internal journal [ 24.009899] EXT3-fs: mounted filesystem with ordered data mode. [ 24.053164] eth0: Link auto-negotiation speed 100M bps full duplex [ 28.733360] agpgart: Found an AGP 3.0 compliant device at :00:00.0. [ 28.733872] agpgart: Putting AGP V3 device at :00:00.0 into 8x mode [ 28.734354] agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [ 29.089412] [drm] Setting GART location based on new memory map [ 29.089842] [drm] Loading R200 Microcode [ 29.090172] [drm] writeback test succeeded in 1 usecs [ 143.076821] Marking TSC unstable due to: cpufreq changes. [ 143.084910] Time: hpet clocksource has been installed. [ 143.670905] Clocksource tsc unstable (delta = -231086796 ns) So the TSC is being marked unstable because of cpufreq changes. I have no idea when it comes to TSCs and HPETs and how the RTC works (other than what the abbreviations stand for), so this all may be meaningless. I'll try disabling cpufreq to see if that has an effect. -- Kevin Winchester -- 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/
hwclock failure in x86.git
ONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set CONFIG_NLS_KOI8_R=y # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # CONFIG_INSTRUMENTATION is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y CONFIG_ENABLE_WARN_DEPRECATED=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_SLUB_DEBUG_ON is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_LOCKDEP is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y CONFIG_FORCED_INLINING=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_UNWIND_INFO is not set # CONFIG_KGDB is not set # CONFIG_KGDB_ATTACH_WAIT is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_RODATA is not set CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 # CONFIG_IO_DELAY_0X80 is not set # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set CONFIG_IO_DELAY_NONE=y CONFIG_DEFAULT_IO_DELAY_TYPE=3 # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_GF128MUL is not set CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_CBC is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_XTS is not set # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_586 is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_AES_586 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=y # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set CONFIG_CRC_ITU_T=y CONFIG_CRC32=y # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Kevin Winchester -- 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/
hwclock failure in x86.git
is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set CONFIG_NLS_KOI8_R=y # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # CONFIG_INSTRUMENTATION is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y CONFIG_ENABLE_WARN_DEPRECATED=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_SLUB_DEBUG_ON is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_LOCKDEP is not set CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y CONFIG_FORCED_INLINING=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_UNWIND_INFO is not set # CONFIG_KGDB is not set # CONFIG_KGDB_ATTACH_WAIT is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_RODATA is not set CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 # CONFIG_IO_DELAY_0X80 is not set # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set CONFIG_IO_DELAY_NONE=y CONFIG_DEFAULT_IO_DELAY_TYPE=3 # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_WP512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_GF128MUL is not set CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_CBC is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_XTS is not set # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_586 is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_AES_586 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=y # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_HW is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set CONFIG_CRC_ITU_T=y CONFIG_CRC32=y # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Kevin Winchester -- 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: hwclock failure in x86.git
H. Peter Anvin wrote: Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. A few other facts: - This is an Athlon64 box running X83_32 - I use hpet=force for the Via chipset - A little more of the demsg is: [ 17.511262] rtc_cmos 00:05: setting system clock to 2008-01-10 23:44:16 UTC (128656) [ 17.545948] EXT3-fs: mounted filesystem with ordered data mode. [ 17.545986] VFS: Mounted root (ext3 filesystem) readonly. [ 17.546142] Freeing unused kernel memory: 144k freed [ 17.546260] kjournald starting. Commit interval 5 seconds [ 21.861249] hwclock[622] general protection ip:804b226 sp:bfd98480 error:0 [ 22.416442] Velocity is AUTO mode [ 23.093416] Adding 1502036k swap on /dev/sda5. Priority:-1 extents:1 across:1502036k [ 23.416756] EXT3 FS on sda1, internal journal [ 24.009669] kjournald starting. Commit interval 5 seconds [ 24.009889] EXT3 FS on sda6, internal journal [ 24.009899] EXT3-fs: mounted filesystem with ordered data mode. [ 24.053164] eth0: Link auto-negotiation speed 100M bps full duplex [ 28.733360] agpgart: Found an AGP 3.0 compliant device at :00:00.0. [ 28.733872] agpgart: Putting AGP V3 device at :00:00.0 into 8x mode [ 28.734354] agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [ 29.089412] [drm] Setting GART location based on new memory map [ 29.089842] [drm] Loading R200 Microcode [ 29.090172] [drm] writeback test succeeded in 1 usecs [ 143.076821] Marking TSC unstable due to: cpufreq changes. [ 143.084910] Time: hpet clocksource has been installed. [ 143.670905] Clocksource tsc unstable (delta = -231086796 ns) So the TSC is being marked unstable because of cpufreq changes. I have no idea when it comes to TSCs and HPETs and how the RTC works (other than what the abbreviations stand for), so this all may be meaningless. I'll try disabling cpufreq to see if that has an effect. -- Kevin Winchester -- 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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Kevin Winchester wrote:
H. Peter Anvin wrote:
Kevin Winchester wrote:
My first time building and booting the mm branch of x86.git was pretty
successful. The only error I noticed was the following in my dmesg:
hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
I'm not sure exactly how to debug this. I could bisect, but there seems
to be some useful debug information in there, so there might be
something better to try first.
That's a userspace IP; it implies the userspace hwclock binary did
something bad, or the kernel didn't permit it to do something it should
have. The best thing to do would probably to strace hwclock and see
what it did when it died.
Unfortunately, but the time I can get a chance to run hwclock, the
problem seems to have fixed itself. I tried booting into single user
mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
The other thing you can do is to download the debug information and
source code for hwclock from your particular distro, and find out
exactly what operation inside the hwclock binary is triggering the segfault.
The only other option is to bisect.
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
I'll take a look at the unification and see if I can see anything obvious.
--
Kevin Winchester [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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Kevin Winchester wrote:
H. Peter Anvin wrote:
Kevin Winchester wrote:
My first time building and booting the mm branch of x86.git was pretty
successful. The only error I noticed was the following in my dmesg:
hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
I'm not sure exactly how to debug this. I could bisect, but there seems
to be some useful debug information in there, so there might be
something better to try first.
That's a userspace IP; it implies the userspace hwclock binary did
something bad, or the kernel didn't permit it to do something it should
have. The best thing to do would probably to strace hwclock and see
what it did when it died.
Unfortunately, but the time I can get a chance to run hwclock, the
problem seems to have fixed itself. I tried booting into single user
mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
The other thing you can do is to download the debug information and
source code for hwclock from your particular distro, and find out
exactly what operation inside the hwclock binary is triggering the segfault.
The only other option is to bisect.
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
From include/asm-x86/bitops.h:
static inline void clear_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX btr %1,%0
: ADDR
: Ir (nr));
}
static inline void __clear_bit(int nr, volatile void *addr)
{
asm volatile(btr %1,%0 : ADDR : Ir (nr));
}
so it looks like we removed a lock prefix for the 64-bit case. Was that
intentional? Since I'm building for 32-bit, I'm not sure why I was affected,
so maybe my problem is different. Ingo, didn't you have a script somewhere to
test the before and after of unification patches (or am I remembering something
else)?
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8b4a8de..91a1795 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -10,7 +10,7 @@ CFLAGS_vsyscall_64.o := $(PROFILING) -g0
obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
obj-y += traps_$(BITS).o irq_$(BITS).o
-obj-y += time_$(BITS).o ioport_$(BITS).o ldt.o
+obj-y += time_$(BITS).o ioport.o ldt.o
obj-y += setup_$(BITS).o i8259_$(BITS).o
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
new file mode 100644
index 000..e723ff3
--- /dev/null
+++ b/arch/x86/kernel/ioport.c
@@ -0,0 +1,150 @@
+/*
+ * This contains the io-permission bitmap code - written by obz, with changes
+ * by Linus. 32/64 bits code unification by Miguel Botón.
+ */
+
+#include linux/sched.h
+#include linux/kernel.h
+#include linux/capability.h
+#include linux/errno.h
+#include linux/types.h
+#include linux/ioport.h
+#include linux/smp.h
+#include linux/stddef.h
+#include linux/slab.h
+#include linux/thread_info.h
+#include linux/syscalls.h
+
+/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
+static void set_bitmap(unsigned long *bitmap, unsigned int base,
+ unsigned int extent, int new_value)
+{
+ unsigned int i;
+
+ for (i = base; i base + extent; i++) {
+ if (new_value)
+ __set_bit(i, bitmap);
+ else
+ __clear_bit(i, bitmap);
+ }
+}
+
+/*
+ * this changes the io permissions bitmap in the current task.
+ */
+asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+ struct thread_struct * t = current-thread;
+ struct tss_struct * tss;
+ unsigned int i, max_long, bytes, bytes_updated;
+
+ if ((from + num = from) || (from + num IO_BITMAP_BITS))
+ return -EINVAL;
+ if (turn_on !capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ /*
+* If it's the first ioperm() call in this thread's lifetime, set the
+* IO bitmap up. ioperm() is much less timing critical than clone(),
+* this is why we delay this operation until now:
+*/
+ if (!t-io_bitmap_ptr
Re: [patch 1/1] Convert drivers in drivers/char/drm to use .unlocked_ioctl
On Jan 8, 2008 11:37 PM, Dave Airlie <[EMAIL PROTECTED]> wrote: > > > The drm drivers in this patch all used drm_ioctl to perform their > > ioctl calls. The common function is converted to use lock_kernel() > > and unlock_kernel() and the drivers are converted to use .unlocked_ioctl > > > > NAK > > I've started looking at this already in the drm git tree, I'm going to > provide both locked and unlocked paths for drivers to choose, as we need > to audit the drivers on a per-driver basis, the other option is to provide > wrappers in each driver to do the lock/unlock kernel and leave drm_ioctl > alone.. > > I'll take a look kmalloc failure case sounds like a bug though.. > No problem. I interpreted Andi's request for patches as a way to ensure that people were actively working to remove the BKL from ioctl calls. Since you appear to already have been working towards that end, the patch is not really necessary. -- Kevin Winchester -- 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] Convert drivers in drivers/char/drm to use .unlocked_ioctl
On Jan 8, 2008 11:37 PM, Dave Airlie [EMAIL PROTECTED] wrote: The drm drivers in this patch all used drm_ioctl to perform their ioctl calls. The common function is converted to use lock_kernel() and unlock_kernel() and the drivers are converted to use .unlocked_ioctl NAK I've started looking at this already in the drm git tree, I'm going to provide both locked and unlocked paths for drivers to choose, as we need to audit the drivers on a per-driver basis, the other option is to provide wrappers in each driver to do the lock/unlock kernel and leave drm_ioctl alone.. I'll take a look kmalloc failure case sounds like a bug though.. No problem. I interpreted Andi's request for patches as a way to ensure that people were actively working to remove the BKL from ioctl calls. Since you appear to already have been working towards that end, the patch is not really necessary. -- Kevin Winchester -- 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: [JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl
Arnd Bergmann wrote:
> On Wednesday 09 January 2008, Andi Kleen wrote:
>> I imagined it would check for
>>
>> +struct file_operations ... = {
>> + ...
>> + .ioctl = ...
>>
>> That wouldn't catch the case of someone adding only .ioctl to an
>> already existing file_operations which is not visible in the patch context,
>> but that should be hopefully rare. The more common case is adding
>> completely new operations
>
> Right, this would work fine. We can probably even have a list of
> data structures that work like file_operations in this regard.
>
file_operations & block_device_operations are the only two that I can find.
--
Kevin Winchester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] Convert drivers in drivers/char/drm to use .unlocked_ioctl
To: David Airlie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED]
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
Signed-off-by: Kevin Winchester <[EMAIL PROTECTED]>
---
I also noted that in the failed kmalloc case in drm_ioctl(), the function
immediately returns -ENOMEM, rather than following the error path that
calls atomic_dec(>ioctl_count);. I'm not sure if the ioctl_count
is just not important in the -ENOMEM case, or if this is a bug.
drivers/char/drm/drmP.h |3 +--
drivers/char/drm/drm_drv.c| 10 ++
drivers/char/drm/i810_dma.c |2 +-
drivers/char/drm/i810_drv.c |2 +-
drivers/char/drm/i830_dma.c |2 +-
drivers/char/drm/i830_drv.c |2 +-
drivers/char/drm/i915_drv.c |2 +-
drivers/char/drm/mga_drv.c|2 +-
drivers/char/drm/r128_drv.c |2 +-
drivers/char/drm/radeon_drv.c |2 +-
drivers/char/drm/savage_drv.c |2 +-
drivers/char/drm/sis_drv.c|2 +-
drivers/char/drm/tdfx_drv.c |2 +-
drivers/char/drm/via_drv.c|2 +-
14 files changed, 19 insertions(+), 18 deletions(-)
Index: v2.6.24-rc7/drivers/char/drm/drmP.h
===
--- v2.6.24-rc7.orig/drivers/char/drm/drmP.h
+++ v2.6.24-rc7/drivers/char/drm/drmP.h
@@ -833,8 +833,7 @@ static inline int drm_mtrr_del(int handl
/* Driver support (drm_drv.h) */
extern int drm_init(struct drm_driver *driver);
extern void drm_exit(struct drm_driver *driver);
-extern int drm_ioctl(struct inode *inode, struct file *filp,
-unsigned int cmd, unsigned long arg);
+extern long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
extern long drm_compat_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_lastclose(struct drm_device *dev);
Index: v2.6.24-rc7/drivers/char/drm/drm_drv.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/drm_drv.c
+++ v2.6.24-rc7/drivers/char/drm/drm_drv.c
@@ -438,7 +438,6 @@ static int drm_version(struct drm_device
/**
* Called whenever a process performs an ioctl on /dev/drm.
*
- * \param inode device inode.
* \param file_priv DRM file private.
* \param cmd command.
* \param arg user argument.
@@ -447,8 +446,7 @@ static int drm_version(struct drm_device
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev = file_priv->head->dev;
@@ -458,6 +456,7 @@ int drm_ioctl(struct inode *inode, struc
int retcode = -EINVAL;
char *kdata = NULL;
+ lock_kernel();
atomic_inc(>ioctl_count);
atomic_inc(>counts[_DRM_STAT_IOCTLS]);
++file_priv->ioctl_count;
@@ -494,8 +493,10 @@ int drm_ioctl(struct inode *inode, struc
} else {
if (cmd & (IOC_IN | IOC_OUT)) {
kdata = kmalloc(_IOC_SIZE(cmd), GFP_KERNEL);
- if (!kdata)
+ if (!kdata) {
+ unlock_kernel();
return -ENOMEM;
+ }
}
if (cmd & IOC_IN) {
@@ -520,6 +521,7 @@ int drm_ioctl(struct inode *inode, struc
atomic_dec(>ioctl_count);
if (retcode)
DRM_DEBUG("ret = %x\n", retcode);
+ unlock_kernel();
return retcode;
}
Index: v2.6.24-rc7/drivers/char/drm/i810_dma.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/i810_dma.c
+++ v2.6.24-rc7/drivers/char/drm/i810_dma.c
@@ -115,7 +115,7 @@ static int i810_mmap_buffers(struct file
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
};
Index: v2.6.24-rc7/drivers/char/drm/i810_drv.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/i810_drv.c
+++ v2.6.24-rc7/drivers/char/drm/i810_drv.c
@@ -59,7 +59,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioc
Re: [JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl
Andi Kleen wrote: > On Tue, Jan 08, 2008 at 07:50:47PM -0400, Kevin Winchester wrote: >> Andi Kleen wrote: >>> Here's a proposal for some useful code transformations the kernel janitors >>> could do as opposed to running checkpatch.pl. >>> >> >> >> I notice that every driver in drivers/ata uses a .ioctl that points to >> ata_scsi_ioctl(). I could add the BKL to that function, and then change > > This might be a little more complicated. These > are funnelled through the block/SCSI layers which might not have separate > unlocked ioctl callbacks yet. Would be probably not very difficult > to add though. > >> all of the drivers to .unlocked_ioctl, but I assume this would be a >> candidate to actually clean up by determining why the lock is needed and >> removing it if necessary. Does anyone know off-hand the reason for >> needing the lock (I assume someone does or it wouldn't have survived >> this long)? If the lock is absolutely required, then I can write the >> patch to add lock_kernel() and unlock_kernel(). > > Just sending the patch to add lock/unlock_kernel() is probably a good idea > anyways -- > Jeff will then feel bad over it and eventually remove it when he figures out > it is safe ;-) > Sorry about the noise here - I now notice that not all .ioctl function pointers have the option of changing to .unlocked_ioctl. In this case, the ioctl is in the struct scsi_host_template, rather than struct file_operations. I'll try to be a little more careful about the git grepping in the future. -- Kevin Winchester -- 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: [JANITOR PROPOSAL] Switch ioctl functions to ->unlocked_ioctl
Andi Kleen wrote: > Here's a proposal for some useful code transformations the kernel janitors > could do as opposed to running checkpatch.pl. > I notice that every driver in drivers/ata uses a .ioctl that points to ata_scsi_ioctl(). I could add the BKL to that function, and then change all of the drivers to .unlocked_ioctl, but I assume this would be a candidate to actually clean up by determining why the lock is needed and removing it if necessary. Does anyone know off-hand the reason for needing the lock (I assume someone does or it wouldn't have survived this long)? If the lock is absolutely required, then I can write the patch to add lock_kernel() and unlock_kernel(). -- Kevin Winchester -- 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: [JANITOR PROPOSAL] Switch ioctl functions to -unlocked_ioctl
Andi Kleen wrote: Here's a proposal for some useful code transformations the kernel janitors could do as opposed to running checkpatch.pl. snip I notice that every driver in drivers/ata uses a .ioctl that points to ata_scsi_ioctl(). I could add the BKL to that function, and then change all of the drivers to .unlocked_ioctl, but I assume this would be a candidate to actually clean up by determining why the lock is needed and removing it if necessary. Does anyone know off-hand the reason for needing the lock (I assume someone does or it wouldn't have survived this long)? If the lock is absolutely required, then I can write the patch to add lock_kernel() and unlock_kernel(). -- Kevin Winchester -- 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: [JANITOR PROPOSAL] Switch ioctl functions to -unlocked_ioctl
Andi Kleen wrote: On Tue, Jan 08, 2008 at 07:50:47PM -0400, Kevin Winchester wrote: Andi Kleen wrote: Here's a proposal for some useful code transformations the kernel janitors could do as opposed to running checkpatch.pl. snip I notice that every driver in drivers/ata uses a .ioctl that points to ata_scsi_ioctl(). I could add the BKL to that function, and then change This might be a little more complicated. These are funnelled through the block/SCSI layers which might not have separate unlocked ioctl callbacks yet. Would be probably not very difficult to add though. all of the drivers to .unlocked_ioctl, but I assume this would be a candidate to actually clean up by determining why the lock is needed and removing it if necessary. Does anyone know off-hand the reason for needing the lock (I assume someone does or it wouldn't have survived this long)? If the lock is absolutely required, then I can write the patch to add lock_kernel() and unlock_kernel(). Just sending the patch to add lock/unlock_kernel() is probably a good idea anyways -- Jeff will then feel bad over it and eventually remove it when he figures out it is safe ;-) Sorry about the noise here - I now notice that not all .ioctl function pointers have the option of changing to .unlocked_ioctl. In this case, the ioctl is in the struct scsi_host_template, rather than struct file_operations. I'll try to be a little more careful about the git grepping in the future. -- Kevin Winchester -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] Convert drivers in drivers/char/drm to use .unlocked_ioctl
To: David Airlie [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Cc: [EMAIL PROTECTED]
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
I also noted that in the failed kmalloc case in drm_ioctl(), the function
immediately returns -ENOMEM, rather than following the error path that
calls atomic_dec(dev-ioctl_count);. I'm not sure if the ioctl_count
is just not important in the -ENOMEM case, or if this is a bug.
drivers/char/drm/drmP.h |3 +--
drivers/char/drm/drm_drv.c| 10 ++
drivers/char/drm/i810_dma.c |2 +-
drivers/char/drm/i810_drv.c |2 +-
drivers/char/drm/i830_dma.c |2 +-
drivers/char/drm/i830_drv.c |2 +-
drivers/char/drm/i915_drv.c |2 +-
drivers/char/drm/mga_drv.c|2 +-
drivers/char/drm/r128_drv.c |2 +-
drivers/char/drm/radeon_drv.c |2 +-
drivers/char/drm/savage_drv.c |2 +-
drivers/char/drm/sis_drv.c|2 +-
drivers/char/drm/tdfx_drv.c |2 +-
drivers/char/drm/via_drv.c|2 +-
14 files changed, 19 insertions(+), 18 deletions(-)
Index: v2.6.24-rc7/drivers/char/drm/drmP.h
===
--- v2.6.24-rc7.orig/drivers/char/drm/drmP.h
+++ v2.6.24-rc7/drivers/char/drm/drmP.h
@@ -833,8 +833,7 @@ static inline int drm_mtrr_del(int handl
/* Driver support (drm_drv.h) */
extern int drm_init(struct drm_driver *driver);
extern void drm_exit(struct drm_driver *driver);
-extern int drm_ioctl(struct inode *inode, struct file *filp,
-unsigned int cmd, unsigned long arg);
+extern long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
extern long drm_compat_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_lastclose(struct drm_device *dev);
Index: v2.6.24-rc7/drivers/char/drm/drm_drv.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/drm_drv.c
+++ v2.6.24-rc7/drivers/char/drm/drm_drv.c
@@ -438,7 +438,6 @@ static int drm_version(struct drm_device
/**
* Called whenever a process performs an ioctl on /dev/drm.
*
- * \param inode device inode.
* \param file_priv DRM file private.
* \param cmd command.
* \param arg user argument.
@@ -447,8 +446,7 @@ static int drm_version(struct drm_device
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp-private_data;
struct drm_device *dev = file_priv-head-dev;
@@ -458,6 +456,7 @@ int drm_ioctl(struct inode *inode, struc
int retcode = -EINVAL;
char *kdata = NULL;
+ lock_kernel();
atomic_inc(dev-ioctl_count);
atomic_inc(dev-counts[_DRM_STAT_IOCTLS]);
++file_priv-ioctl_count;
@@ -494,8 +493,10 @@ int drm_ioctl(struct inode *inode, struc
} else {
if (cmd (IOC_IN | IOC_OUT)) {
kdata = kmalloc(_IOC_SIZE(cmd), GFP_KERNEL);
- if (!kdata)
+ if (!kdata) {
+ unlock_kernel();
return -ENOMEM;
+ }
}
if (cmd IOC_IN) {
@@ -520,6 +521,7 @@ int drm_ioctl(struct inode *inode, struc
atomic_dec(dev-ioctl_count);
if (retcode)
DRM_DEBUG(ret = %x\n, retcode);
+ unlock_kernel();
return retcode;
}
Index: v2.6.24-rc7/drivers/char/drm/i810_dma.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/i810_dma.c
+++ v2.6.24-rc7/drivers/char/drm/i810_dma.c
@@ -115,7 +115,7 @@ static int i810_mmap_buffers(struct file
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
};
Index: v2.6.24-rc7/drivers/char/drm/i810_drv.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/i810_drv.c
+++ v2.6.24-rc7/drivers/char/drm/i810_drv.c
@@ -59,7 +59,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.ioctl = drm_ioctl,
+.unlocked_ioctl = drm_ioctl
Re: [JANITOR PROPOSAL] Switch ioctl functions to -unlocked_ioctl
Arnd Bergmann wrote:
On Wednesday 09 January 2008, Andi Kleen wrote:
I imagined it would check for
+struct file_operations ... = {
+ ...
+ .ioctl = ...
That wouldn't catch the case of someone adding only .ioctl to an
already existing file_operations which is not visible in the patch context,
but that should be hopefully rare. The more common case is adding
completely new operations
Right, this would work fine. We can probably even have a list of
data structures that work like file_operations in this regard.
file_operations block_device_operations are the only two that I can find.
--
Kevin Winchester
--
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: Top 10 kernel oopses for the week ending January 5th, 2008
J. Bruce Fields wrote: > On Sat, Jan 05, 2008 at 09:39:35PM +, Al Viro wrote: >> On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote: >>> The http://www.kerneloops.org website collects kernel oops and >>> warning reports from various mailing lists and bugzillas as well >>> as with a client users can install to auto-submit oopses. Below >>> is a top 10 list of the oopses collected in the last 7 days. >>> (Reports prior to 2.6.23 have been omitted in collecting the top >>> 10) >>> >>> This week, a total of 49 oopses and warnings have been reported, >>> compared to 53 reports in the previous week. >> FWIW, people moaning about the lack of entry-level kernel work >> would do well by decoding those to the level of "this place in this >> function, called from , with so-and-so variable being >> " and posting the results. As skills go, it's far more >> useful than "how to trim the trailing whitespace" and the rest of >> checkpatch.pl-inspired crap that got so popular lately... > > Is there any good basic documentation on this to point people at? > I would second this question. I see people "decode" oops on lkml often enough, but I've never been entirely sure how its done. Is it somewhere in Documentation? -- Kevin Winchester -- 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: Top 10 kernel oopses for the week ending January 5th, 2008
J. Bruce Fields wrote: On Sat, Jan 05, 2008 at 09:39:35PM +, Al Viro wrote: On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote: The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas as well as with a client users can install to auto-submit oopses. Below is a top 10 list of the oopses collected in the last 7 days. (Reports prior to 2.6.23 have been omitted in collecting the top 10) This week, a total of 49 oopses and warnings have been reported, compared to 53 reports in the previous week. FWIW, people moaning about the lack of entry-level kernel work would do well by decoding those to the level of this place in this function, called from here, with so-and-so variable being this and posting the results. As skills go, it's far more useful than how to trim the trailing whitespace and the rest of checkpatch.pl-inspired crap that got so popular lately... Is there any good basic documentation on this to point people at? I would second this question. I see people decode oops on lkml often enough, but I've never been entirely sure how its done. Is it somewhere in Documentation? -- Kevin Winchester -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] Convert the semaphore to a mutex in net/tipc/socket.c
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Per Liden <[EMAIL PROTECTED]>
Cc: Jon Maloy <[EMAIL PROTECTED]>
Cc: Allan Stephens <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Note also that in the release method, down_interruptible() was being called
without checking the return value. I converted it to mutex_lock_interruptible()
and made the interrupted case return -ERESTARTSYS, as was done for all other
calls to down_interruptible() in the file.
Signed-off-by: Kevin Winchester <[EMAIL PROTECTED]>
---
net/tipc/socket.c | 56 +++---
1 file changed, 28 insertions(+), 28 deletions(-)
Index: v2.6.24-rc4/net/tipc/socket.c
===
--- v2.6.24-rc4.orig/net/tipc/socket.c
+++ v2.6.24-rc4/net/tipc/socket.c
@@ -63,7 +63,7 @@
struct tipc_sock {
struct sock sk;
struct tipc_port *p;
- struct semaphore sem;
+ struct mutex lock;
};
#define tipc_sk(sk) ((struct tipc_sock*)sk)
@@ -217,7 +217,7 @@ static int tipc_create(struct net *net,
tsock->p = port;
port->usr_handle = tsock;
- init_MUTEX(>sem);
+ mutex_init(>lock);
dbg("sock_create: %x\n",tsock);
@@ -253,9 +253,10 @@ static int release(struct socket *sock)
dbg("sock_delete: %x\n",tsock);
if (!tsock)
return 0;
- down_interruptible(>sem);
+ if (mutex_lock_interruptible(>lock))
+ return -ERESTARTSYS;
if (!sock->sk) {
- up(>sem);
+ mutex_unlock(>lock);
return 0;
}
@@ -288,7 +289,7 @@ static int release(struct socket *sock)
atomic_dec(_queue_size);
}
- up(>sem);
+ mutex_unlock(>lock);
sock_put(sk);
@@ -315,7 +316,7 @@ static int bind(struct socket *sock, str
struct sockaddr_tipc *addr = (struct sockaddr_tipc *)uaddr;
int res;
- if (down_interruptible(>sem))
+ if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
if (unlikely(!uaddr_len)) {
@@ -346,7 +347,7 @@ static int bind(struct socket *sock, str
res = tipc_withdraw(tsock->p->ref, -addr->scope,
>addr.nameseq);
exit:
- up(>sem);
+ mutex_unlock(>lock);
return res;
}
@@ -367,7 +368,7 @@ static int get_name(struct socket *sock,
struct sockaddr_tipc *addr = (struct sockaddr_tipc *)uaddr;
u32 res;
- if (down_interruptible(>sem))
+ if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
*uaddr_len = sizeof(*addr);
@@ -380,7 +381,7 @@ static int get_name(struct socket *sock,
res = tipc_ownidentity(tsock->p->ref, >addr.id);
addr->addr.name.domain = 0;
- up(>sem);
+ mutex_unlock(>lock);
return res;
}
@@ -477,7 +478,7 @@ static int send_msg(struct kiocb *iocb,
}
}
- if (down_interruptible(>sem))
+ if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
if (needs_conn) {
@@ -523,7 +524,7 @@ static int send_msg(struct kiocb *iocb,
}
if (likely(res != -ELINKCONG)) {
exit:
- up(>sem);
+ mutex_unlock(>lock);
return res;
}
if (m->msg_flags & MSG_DONTWAIT) {
@@ -562,9 +563,8 @@ static int send_packet(struct kiocb *ioc
if (unlikely(dest))
return send_msg(iocb, sock, m, total_len);
- if (down_interruptible(>sem)) {
+ if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
- }
do {
if (unlikely(sock->state != SS_CONNECTED)) {
@@ -578,7 +578,7 @@ static int send_packet(struct kiocb *ioc
res = tipc_send(tsock->p->ref, m->msg_iovlen, m->msg_iov);
if (likely(res != -ELINKCONG)) {
exit:
- up(>sem);
+ mutex_unlock(>lock);
return res;
}
if (m->msg_flags & MSG_DONTWAIT) {
@@ -846,7 +846,7 @@ static int recv_msg(struct kiocb *iocb,
/* Look for a message in receive queue; wait if necessary */
- if (unlikely(down_interruptible(>sem)))
+ if (unlikely(mutex_lock_interruptible(>lock)))
return -ERESTARTSYS;
restart:
@@ -930,7 +930,7 @@ restart:
advance_queue(tsock);
}
exit:
- up(>sem);
+ mutex_unlock(>lock);
return res;
}
@@ -981,7 +981,7 @@ static int recv_stream(struct kiocb *ioc
[patch 2/2] 9p util semaphore to mutex
Convert the semaphore to a mutex in net/9p/util.c
Signed-off-by: Kevin Winchester <[EMAIL PROTECTED]>
---
net/9p/util.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: v2.6.24-rc4/net/9p/util.c
===
--- v2.6.24-rc4.orig/net/9p/util.c
+++ v2.6.24-rc4/net/9p/util.c
@@ -33,7 +33,7 @@
#include
struct p9_idpool {
- struct semaphore lock;
+ struct mutex lock;
struct idr pool;
};
@@ -45,7 +45,7 @@ struct p9_idpool *p9_idpool_create(void)
if (!p)
return ERR_PTR(-ENOMEM);
- init_MUTEX(>lock);
+ mutex_init(>lock);
idr_init(>pool);
return p;
@@ -76,14 +76,14 @@ retry:
if (idr_pre_get(>pool, GFP_KERNEL) == 0)
return 0;
- if (down_interruptible(>lock) == -EINTR) {
+ if (mutex_lock_interruptible(>lock) == -EINTR) {
P9_EPRINTK(KERN_WARNING, "Interrupted while locking\n");
return -1;
}
/* no need to store exactly p, we just need something non-null */
error = idr_get_new(>pool, p, );
- up(>lock);
+ mutex_unlock(>lock);
if (error == -EAGAIN)
goto retry;
@@ -104,12 +104,12 @@ EXPORT_SYMBOL(p9_idpool_get);
void p9_idpool_put(int id, struct p9_idpool *p)
{
- if (down_interruptible(>lock) == -EINTR) {
+ if (mutex_lock_interruptible(>lock) == -EINTR) {
P9_EPRINTK(KERN_WARNING, "Interrupted while locking\n");
return;
}
idr_remove(>pool, id);
- up(>lock);
+ mutex_unlock(>lock);
}
EXPORT_SYMBOL(p9_idpool_put);
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] echoaudio semaphore to mutex
Convert the semaphore to a mutex in echoaudio.c
Signed-off-by: Kevin Winchester <[EMAIL PROTECTED]>
---
sound/pci/echoaudio/echoaudio.c | 18 +-
sound/pci/echoaudio/echoaudio.h |2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
Index: v2.6.24-rc4/sound/pci/echoaudio/echoaudio.c
===
--- v2.6.24-rc4.orig/sound/pci/echoaudio/echoaudio.c
+++ v2.6.24-rc4/sound/pci/echoaudio/echoaudio.c
@@ -378,7 +378,7 @@ static int pcm_digital_in_open(struct sn
DE_ACT(("pcm_digital_in_open\n"));
max_channels = num_digital_busses_in(chip) - substream->number;
- down(>mode_mutex);
+ mutex_lock(>mode_mutex);
if (chip->digital_mode == DIGITAL_MODE_ADAT)
err = pcm_open(substream, max_channels);
else/* If the card has ADAT, subtract the 6 channels
@@ -405,7 +405,7 @@ static int pcm_digital_in_open(struct sn
chip->can_set_rate=0;
din_exit:
- up(>mode_mutex);
+ mutex_unlock(>mode_mutex);
return err;
}
@@ -420,7 +420,7 @@ static int pcm_digital_out_open(struct s
DE_ACT(("pcm_digital_out_open\n"));
max_channels = num_digital_busses_out(chip) - substream->number;
- down(>mode_mutex);
+ mutex_lock(>mode_mutex);
if (chip->digital_mode == DIGITAL_MODE_ADAT)
err = pcm_open(substream, max_channels);
else/* If the card has ADAT, subtract the 6 channels
@@ -447,7 +447,7 @@ static int pcm_digital_out_open(struct s
if (atomic_read(>opencount) > 1 && chip->rate_set)
chip->can_set_rate=0;
dout_exit:
- up(>mode_mutex);
+ mutex_unlock(>mode_mutex);
return err;
}
@@ -1420,7 +1420,7 @@ static int snd_echo_digital_mode_put(str
if (dmode != chip->digital_mode) {
/* mode_mutex is required to make this operation atomic wrt
pcm_digital_*_open() and set_input_clock() functions. */
- down(>mode_mutex);
+ mutex_lock(>mode_mutex);
/* Do not allow the user to change the digital mode when a pcm
device is open because it also changes the number of channels
@@ -1439,7 +1439,7 @@ static int snd_echo_digital_mode_put(str
if (changed >= 0)
changed = 1;/* No errors */
}
- up(>mode_mutex);
+ mutex_unlock(>mode_mutex);
}
return changed;
}
@@ -1566,12 +1566,12 @@ static int snd_echo_clock_source_put(str
return -EINVAL;
dclock = chip->clock_source_list[eclock];
if (chip->input_clock != dclock) {
- down(>mode_mutex);
+ mutex_lock(>mode_mutex);
spin_lock_irq(>lock);
if ((changed = set_input_clock(chip, dclock)) == 0)
changed = 1;/* no errors */
spin_unlock_irq(>lock);
- up(>mode_mutex);
+ mutex_unlock(>mode_mutex);
}
if (changed < 0)
@@ -1972,7 +1972,7 @@ static __devinit int snd_echo_create(str
return err;
}
atomic_set(>opencount, 0);
- init_MUTEX(>mode_mutex);
+ mutex_init(>mode_mutex);
chip->can_set_rate = 1;
*rchip = chip;
/* Init done ! */
Index: v2.6.24-rc4/sound/pci/echoaudio/echoaudio.h
===
--- v2.6.24-rc4.orig/sound/pci/echoaudio/echoaudio.h
+++ v2.6.24-rc4/sound/pci/echoaudio/echoaudio.h
@@ -361,7 +361,7 @@ struct echoaudio {
spinlock_t lock;
struct snd_pcm_substream *substream[DSP_MAXPIPES];
int last_period[DSP_MAXPIPES];
- struct semaphore mode_mutex;
+ struct mutex mode_mutex;
u16 num_digital_modes, digital_mode_list[6];
u16 num_clock_sources, clock_source_list[10];
atomic_t opencount;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] echoaudio semaphore to mutex
Convert the semaphore to a mutex in echoaudio.c
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
sound/pci/echoaudio/echoaudio.c | 18 +-
sound/pci/echoaudio/echoaudio.h |2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
Index: v2.6.24-rc4/sound/pci/echoaudio/echoaudio.c
===
--- v2.6.24-rc4.orig/sound/pci/echoaudio/echoaudio.c
+++ v2.6.24-rc4/sound/pci/echoaudio/echoaudio.c
@@ -378,7 +378,7 @@ static int pcm_digital_in_open(struct sn
DE_ACT((pcm_digital_in_open\n));
max_channels = num_digital_busses_in(chip) - substream-number;
- down(chip-mode_mutex);
+ mutex_lock(chip-mode_mutex);
if (chip-digital_mode == DIGITAL_MODE_ADAT)
err = pcm_open(substream, max_channels);
else/* If the card has ADAT, subtract the 6 channels
@@ -405,7 +405,7 @@ static int pcm_digital_in_open(struct sn
chip-can_set_rate=0;
din_exit:
- up(chip-mode_mutex);
+ mutex_unlock(chip-mode_mutex);
return err;
}
@@ -420,7 +420,7 @@ static int pcm_digital_out_open(struct s
DE_ACT((pcm_digital_out_open\n));
max_channels = num_digital_busses_out(chip) - substream-number;
- down(chip-mode_mutex);
+ mutex_lock(chip-mode_mutex);
if (chip-digital_mode == DIGITAL_MODE_ADAT)
err = pcm_open(substream, max_channels);
else/* If the card has ADAT, subtract the 6 channels
@@ -447,7 +447,7 @@ static int pcm_digital_out_open(struct s
if (atomic_read(chip-opencount) 1 chip-rate_set)
chip-can_set_rate=0;
dout_exit:
- up(chip-mode_mutex);
+ mutex_unlock(chip-mode_mutex);
return err;
}
@@ -1420,7 +1420,7 @@ static int snd_echo_digital_mode_put(str
if (dmode != chip-digital_mode) {
/* mode_mutex is required to make this operation atomic wrt
pcm_digital_*_open() and set_input_clock() functions. */
- down(chip-mode_mutex);
+ mutex_lock(chip-mode_mutex);
/* Do not allow the user to change the digital mode when a pcm
device is open because it also changes the number of channels
@@ -1439,7 +1439,7 @@ static int snd_echo_digital_mode_put(str
if (changed = 0)
changed = 1;/* No errors */
}
- up(chip-mode_mutex);
+ mutex_unlock(chip-mode_mutex);
}
return changed;
}
@@ -1566,12 +1566,12 @@ static int snd_echo_clock_source_put(str
return -EINVAL;
dclock = chip-clock_source_list[eclock];
if (chip-input_clock != dclock) {
- down(chip-mode_mutex);
+ mutex_lock(chip-mode_mutex);
spin_lock_irq(chip-lock);
if ((changed = set_input_clock(chip, dclock)) == 0)
changed = 1;/* no errors */
spin_unlock_irq(chip-lock);
- up(chip-mode_mutex);
+ mutex_unlock(chip-mode_mutex);
}
if (changed 0)
@@ -1972,7 +1972,7 @@ static __devinit int snd_echo_create(str
return err;
}
atomic_set(chip-opencount, 0);
- init_MUTEX(chip-mode_mutex);
+ mutex_init(chip-mode_mutex);
chip-can_set_rate = 1;
*rchip = chip;
/* Init done ! */
Index: v2.6.24-rc4/sound/pci/echoaudio/echoaudio.h
===
--- v2.6.24-rc4.orig/sound/pci/echoaudio/echoaudio.h
+++ v2.6.24-rc4/sound/pci/echoaudio/echoaudio.h
@@ -361,7 +361,7 @@ struct echoaudio {
spinlock_t lock;
struct snd_pcm_substream *substream[DSP_MAXPIPES];
int last_period[DSP_MAXPIPES];
- struct semaphore mode_mutex;
+ struct mutex mode_mutex;
u16 num_digital_modes, digital_mode_list[6];
u16 num_clock_sources, clock_source_list[10];
atomic_t opencount;
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/2] 9p util semaphore to mutex
Convert the semaphore to a mutex in net/9p/util.c
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
net/9p/util.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: v2.6.24-rc4/net/9p/util.c
===
--- v2.6.24-rc4.orig/net/9p/util.c
+++ v2.6.24-rc4/net/9p/util.c
@@ -33,7 +33,7 @@
#include net/9p/9p.h
struct p9_idpool {
- struct semaphore lock;
+ struct mutex lock;
struct idr pool;
};
@@ -45,7 +45,7 @@ struct p9_idpool *p9_idpool_create(void)
if (!p)
return ERR_PTR(-ENOMEM);
- init_MUTEX(p-lock);
+ mutex_init(p-lock);
idr_init(p-pool);
return p;
@@ -76,14 +76,14 @@ retry:
if (idr_pre_get(p-pool, GFP_KERNEL) == 0)
return 0;
- if (down_interruptible(p-lock) == -EINTR) {
+ if (mutex_lock_interruptible(p-lock) == -EINTR) {
P9_EPRINTK(KERN_WARNING, Interrupted while locking\n);
return -1;
}
/* no need to store exactly p, we just need something non-null */
error = idr_get_new(p-pool, p, i);
- up(p-lock);
+ mutex_unlock(p-lock);
if (error == -EAGAIN)
goto retry;
@@ -104,12 +104,12 @@ EXPORT_SYMBOL(p9_idpool_get);
void p9_idpool_put(int id, struct p9_idpool *p)
{
- if (down_interruptible(p-lock) == -EINTR) {
+ if (mutex_lock_interruptible(p-lock) == -EINTR) {
P9_EPRINTK(KERN_WARNING, Interrupted while locking\n);
return;
}
idr_remove(p-pool, id);
- up(p-lock);
+ mutex_unlock(p-lock);
}
EXPORT_SYMBOL(p9_idpool_put);
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] Convert the semaphore to a mutex in net/tipc/socket.c
To: Andrew Morton [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Per Liden [EMAIL PROTECTED]
Cc: Jon Maloy [EMAIL PROTECTED]
Cc: Allan Stephens [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Note also that in the release method, down_interruptible() was being called
without checking the return value. I converted it to mutex_lock_interruptible()
and made the interrupted case return -ERESTARTSYS, as was done for all other
calls to down_interruptible() in the file.
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
net/tipc/socket.c | 56 +++---
1 file changed, 28 insertions(+), 28 deletions(-)
Index: v2.6.24-rc4/net/tipc/socket.c
===
--- v2.6.24-rc4.orig/net/tipc/socket.c
+++ v2.6.24-rc4/net/tipc/socket.c
@@ -63,7 +63,7 @@
struct tipc_sock {
struct sock sk;
struct tipc_port *p;
- struct semaphore sem;
+ struct mutex lock;
};
#define tipc_sk(sk) ((struct tipc_sock*)sk)
@@ -217,7 +217,7 @@ static int tipc_create(struct net *net,
tsock-p = port;
port-usr_handle = tsock;
- init_MUTEX(tsock-sem);
+ mutex_init(tsock-lock);
dbg(sock_create: %x\n,tsock);
@@ -253,9 +253,10 @@ static int release(struct socket *sock)
dbg(sock_delete: %x\n,tsock);
if (!tsock)
return 0;
- down_interruptible(tsock-sem);
+ if (mutex_lock_interruptible(tsock-lock))
+ return -ERESTARTSYS;
if (!sock-sk) {
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
return 0;
}
@@ -288,7 +289,7 @@ static int release(struct socket *sock)
atomic_dec(tipc_queue_size);
}
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
sock_put(sk);
@@ -315,7 +316,7 @@ static int bind(struct socket *sock, str
struct sockaddr_tipc *addr = (struct sockaddr_tipc *)uaddr;
int res;
- if (down_interruptible(tsock-sem))
+ if (mutex_lock_interruptible(tsock-lock))
return -ERESTARTSYS;
if (unlikely(!uaddr_len)) {
@@ -346,7 +347,7 @@ static int bind(struct socket *sock, str
res = tipc_withdraw(tsock-p-ref, -addr-scope,
addr-addr.nameseq);
exit:
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
return res;
}
@@ -367,7 +368,7 @@ static int get_name(struct socket *sock,
struct sockaddr_tipc *addr = (struct sockaddr_tipc *)uaddr;
u32 res;
- if (down_interruptible(tsock-sem))
+ if (mutex_lock_interruptible(tsock-lock))
return -ERESTARTSYS;
*uaddr_len = sizeof(*addr);
@@ -380,7 +381,7 @@ static int get_name(struct socket *sock,
res = tipc_ownidentity(tsock-p-ref, addr-addr.id);
addr-addr.name.domain = 0;
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
return res;
}
@@ -477,7 +478,7 @@ static int send_msg(struct kiocb *iocb,
}
}
- if (down_interruptible(tsock-sem))
+ if (mutex_lock_interruptible(tsock-lock))
return -ERESTARTSYS;
if (needs_conn) {
@@ -523,7 +524,7 @@ static int send_msg(struct kiocb *iocb,
}
if (likely(res != -ELINKCONG)) {
exit:
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
return res;
}
if (m-msg_flags MSG_DONTWAIT) {
@@ -562,9 +563,8 @@ static int send_packet(struct kiocb *ioc
if (unlikely(dest))
return send_msg(iocb, sock, m, total_len);
- if (down_interruptible(tsock-sem)) {
+ if (mutex_lock_interruptible(tsock-lock))
return -ERESTARTSYS;
- }
do {
if (unlikely(sock-state != SS_CONNECTED)) {
@@ -578,7 +578,7 @@ static int send_packet(struct kiocb *ioc
res = tipc_send(tsock-p-ref, m-msg_iovlen, m-msg_iov);
if (likely(res != -ELINKCONG)) {
exit:
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
return res;
}
if (m-msg_flags MSG_DONTWAIT) {
@@ -846,7 +846,7 @@ static int recv_msg(struct kiocb *iocb,
/* Look for a message in receive queue; wait if necessary */
- if (unlikely(down_interruptible(tsock-sem)))
+ if (unlikely(mutex_lock_interruptible(tsock-lock)))
return -ERESTARTSYS;
restart:
@@ -930,7 +930,7 @@ restart:
advance_queue(tsock);
}
exit:
- up(tsock-sem);
+ mutex_unlock(tsock-lock);
return res;
}
@@ -981,7 +981,7 @@ static int recv_stream(struct kiocb *ioc
/* Look for a message in receive queue; wait if necessary */
- if (unlikely
Re: Possible locking issue in viotape.c
Daniel Walker wrote: >> Yes, you are right, I hadn't finished looking at all of the up() calls >> when I came to my conclusion. I will try to convert a few that are not >> on your list, but I would like to know how you are generating your >> patches into those files with the diffstat and recipient list. Is that >> a feature of some git command? > > Git may have a similar feature, but I'm using a tool call Quilt. It's > used for managing a list of patches, and it can automatically add a > diffstat to the patch header (part of the quilt refresh command). I also > use it for emailing a list of patches. > Yes, I've used quilt for working with mm patches in the past, but I'm not too familiar with the mail features. For example, how do you get the recipient list and Signed-off-by in the patch file? Do you just edit it by hand? Or is there some guide to quilt I should be reading? I looked at the guide in /usr/share/doc/quilt/quilt.pdf, but it didn't have anything about email. /usr/share/doc/quilt/README.MAIL has the details of all of the mail options, but doesn't give a nice example of what to do with the patch file and how to call 'quilt mail'. -- Kevin Winchester -- 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: Possible locking issue in viotape.c
Daniel Walker wrote: > On Thu, 2007-12-06 at 21:29 -0400, Kevin Winchester wrote: >> Daniel Walker wrote: >>> I've posted all the ones I've done so far .. >>> >>> ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ >>> >>> Feel free to review or test them.. I've found it pretty easy to simply >>> grep for certain class of semaphore usage, check if it's conforming to >>> the mutex requirements, then convert it or not.. Checking them is >>> getting to be a habit, so I don't think a list would help me.. However, >>> someone else might be able to use it.. >>> >> Thanks, that helps me not duplicate anything. One of the first ones I >> was looking at (before your post) was viotape.c, which is in your patch >> set. However, looking at the uses of the semaphore, I see that on line >> 409-410 the following code: >> >> if (noblock) >> return count; >> >> which seems to ignore the fact that the semaphore has been downed (not >> to mention the dma buffer and op struct allocations. I think it should be: >> >> if (noblock) >> ret = count; >> goto free_dma; >> >> instead. Do you want to make sure I'm right about that and fold it into >> your patch? Or have you already submitted your patch (or should it be >> in a separate patch? Alternatively, I can submit the patch if you don't >> want to bother with it. > > viotape was one of the first I started converting, but later I noticed > the same thing you found above. I have it commented out of my series for > that reason .. > > I think this noblock path is actually doing what the author intended.. > There are a few stray up() calls related to event handling and ioctls , > and I think those are used to release the semaphore.. > > Daniel > > Yes, you are right, I hadn't finished looking at all of the up() calls when I came to my conclusion. I will try to convert a few that are not on your list, but I would like to know how you are generating your patches into those files with the diffstat and recipient list. Is that a feature of some git command? -- Kevin Winchester -- 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: Possible locking issue in viotape.c
Daniel Walker wrote: On Thu, 2007-12-06 at 21:29 -0400, Kevin Winchester wrote: Daniel Walker wrote: I've posted all the ones I've done so far .. ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it.. Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code: if (noblock) return count; which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be: if (noblock) ret = count; goto free_dma; instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it. viotape was one of the first I started converting, but later I noticed the same thing you found above. I have it commented out of my series for that reason .. I think this noblock path is actually doing what the author intended.. There are a few stray up() calls related to event handling and ioctls , and I think those are used to release the semaphore.. Daniel Yes, you are right, I hadn't finished looking at all of the up() calls when I came to my conclusion. I will try to convert a few that are not on your list, but I would like to know how you are generating your patches into those files with the diffstat and recipient list. Is that a feature of some git command? -- Kevin Winchester -- 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: Possible locking issue in viotape.c
Daniel Walker wrote: Yes, you are right, I hadn't finished looking at all of the up() calls when I came to my conclusion. I will try to convert a few that are not on your list, but I would like to know how you are generating your patches into those files with the diffstat and recipient list. Is that a feature of some git command? Git may have a similar feature, but I'm using a tool call Quilt. It's used for managing a list of patches, and it can automatically add a diffstat to the patch header (part of the quilt refresh command). I also use it for emailing a list of patches. Yes, I've used quilt for working with mm patches in the past, but I'm not too familiar with the mail features. For example, how do you get the recipient list and Signed-off-by in the patch file? Do you just edit it by hand? Or is there some guide to quilt I should be reading? I looked at the guide in /usr/share/doc/quilt/quilt.pdf, but it didn't have anything about email. /usr/share/doc/quilt/README.MAIL has the details of all of the mail options, but doesn't give a nice example of what to do with the patch file and how to call 'quilt mail'. -- Kevin Winchester -- 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/
Possible locking issue in viotape.c
Daniel Walker wrote: > > I've posted all the ones I've done so far .. > > ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ > > Feel free to review or test them.. I've found it pretty easy to simply > grep for certain class of semaphore usage, check if it's conforming to > the mutex requirements, then convert it or not.. Checking them is > getting to be a habit, so I don't think a list would help me.. However, > someone else might be able to use it.. > Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code: if (noblock) return count; which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be: if (noblock) ret = count; goto free_dma; instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it. -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] printer port driver: semaphore to mutex
Daniel Walker wrote: > On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: >> * Daniel Walker <[EMAIL PROTECTED]> wrote: >> >>> The port_mutex is actually a semaphore, so easily converted to a >>> struct mutex. >>> >>> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> >> Acked-by: Ingo Molnar <[EMAIL PROTECTED]> >> >> cool. How far away are we from being able to remove all the semaphore >> code? :-) > > I wish my 7 patches made a dent, but it's hasn't done much. ;( > > I would guess at least a week just to mop up the relatively easy ones.. > I've got 12 in my queue, and there still ~50 hopefully trivial ones > still to be looked at.. Then another ~30 more difficult ones (that use > init_MUTEX_LOCKED, or sema_init with 0 instead of 1) .. > I didn't realise there were so many of these patch sets still to go. I could probably help out with some of them. Is there somewhere we could keep track of which ones are left to do, and who is handling them? If it would be helpful, I could go through all of the semaphore uses in the tree and try to figure out which (if any) are true counting semaphores that cannot be converted, and then I could post/send the list of convertible cases. Would that be helpful, or has it already been done somewhere else? -- Kevin Winchester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] printer port driver: semaphore to mutex
Daniel Walker wrote: On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: The port_mutex is actually a semaphore, so easily converted to a struct mutex. Signed-off-by: Daniel Walker [EMAIL PROTECTED] Acked-by: Ingo Molnar [EMAIL PROTECTED] cool. How far away are we from being able to remove all the semaphore code? :-) I wish my 7 patches made a dent, but it's hasn't done much. ;( I would guess at least a week just to mop up the relatively easy ones.. I've got 12 in my queue, and there still ~50 hopefully trivial ones still to be looked at.. Then another ~30 more difficult ones (that use init_MUTEX_LOCKED, or sema_init with 0 instead of 1) .. I didn't realise there were so many of these patch sets still to go. I could probably help out with some of them. Is there somewhere we could keep track of which ones are left to do, and who is handling them? If it would be helpful, I could go through all of the semaphore uses in the tree and try to figure out which (if any) are true counting semaphores that cannot be converted, and then I could post/send the list of convertible cases. Would that be helpful, or has it already been done somewhere else? -- Kevin Winchester -- 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/
Possible locking issue in viotape.c
Daniel Walker wrote: I've posted all the ones I've done so far .. ftp://source.mvista.com/pub/dwalker/sem2mutex-2.6.24-rc4/ Feel free to review or test them.. I've found it pretty easy to simply grep for certain class of semaphore usage, check if it's conforming to the mutex requirements, then convert it or not.. Checking them is getting to be a habit, so I don't think a list would help me.. However, someone else might be able to use it.. Thanks, that helps me not duplicate anything. One of the first ones I was looking at (before your post) was viotape.c, which is in your patch set. However, looking at the uses of the semaphore, I see that on line 409-410 the following code: if (noblock) return count; which seems to ignore the fact that the semaphore has been downed (not to mention the dma buffer and op struct allocations. I think it should be: if (noblock) ret = count; goto free_dma; instead. Do you want to make sure I'm right about that and fold it into your patch? Or have you already submitted your patch (or should it be in a separate patch? Alternatively, I can submit the patch if you don't want to bother with it. -- Kevin Winchester -- 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 mmotm] Fix missing closing parenthesis in binfmt_elf.c
An obviously missing closing parenthesis.
Signed-off-by: Kevin Winchester <[EMAIL PROTECTED]>
---
This is more for practice sending patches than anything else, to make
sure they are not damaged in any way.
But it does bring up a good question. Are patches expected/wanted for
the mmotm kernels?
Index: linux-mm/fs/binfmt_elf.c
===
--- linux-mm.orig/fs/binfmt_elf.c 2007-11-19 20:01:00.0 -0400
+++ linux-mm/fs/binfmt_elf.c2007-11-19 20:02:34.0 -0400
@@ -1031,7 +1031,7 @@
}
if (elf_interpreter) {
- if (IS_AOUT_INTERP(interpreter_type) {
+ if (IS_AOUT_INTERP(interpreter_type)) {
elf_entry = load_aout_interp(>interp_ex,
interpreter);
} else {
-
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 mmotm] Fix missing closing parenthesis in binfmt_elf.c
An obviously missing closing parenthesis.
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
This is more for practice sending patches than anything else, to make
sure they are not damaged in any way.
But it does bring up a good question. Are patches expected/wanted for
the mmotm kernels?
Index: linux-mm/fs/binfmt_elf.c
===
--- linux-mm.orig/fs/binfmt_elf.c 2007-11-19 20:01:00.0 -0400
+++ linux-mm/fs/binfmt_elf.c2007-11-19 20:02:34.0 -0400
@@ -1031,7 +1031,7 @@
}
if (elf_interpreter) {
- if (IS_AOUT_INTERP(interpreter_type) {
+ if (IS_AOUT_INTERP(interpreter_type)) {
elf_entry = load_aout_interp(loc-interp_ex,
interpreter);
} else {
-
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-rc2-mm1 -- strange apparent network failures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
> Kevin,
>
> Can you try this quick hack?
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index e57d1aa..4088610 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,7 +109,7 @@ out:
> kdata[i].permitted = pP.cap[i];
> kdata[i].inheritable = pI.cap[i];
> }
> - while (i < _LINUX_CAPABILITY_U32S) {
> + while (0 && (i < _LINUX_CAPABILITY_U32S)) {
> if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {
> /* Cannot represent w/ legacy structure */
> return -ERANGE;
>
Oh, and the reason your patch turned up incorrect in my mailer and on
lkml seems to be the PGP signature. I didn't have your public key, so
my mail client just left the full PGP-signed text in, which includes
escaping of '-' characters. LKML must also ignore the signature. Once
I added your public key, the patch shows up correctly in my client at least.
(I guess everyone else probably knew this already...but at least I
learned something new today)
- --
Kevin Winchester
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP5QdKPGFQbiQ3tQRAqimAJwOSGDSM2wXeLbm+sBKehGf/haNpACfX7Cb
IALnPxwlgShR6Xb+XQclBro=
=xFUp
-END PGP SIGNATURE-
-
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-rc2-mm1 -- strange apparent network failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Winchester wrote: > Looking at the code being bypassed: > > if (pE.cap[i] || pP.cap[i] || pP.cap[i]) > > looks somewhat weird as it is testing the same condition twice. Should > it have been: > > if (pE.cap[i] || pP.cap[i] || pI.cap[i]) > > ? > > I'm about to test that change instead of bypassing the loop, so I'll let > you know the results. > No, this still results in a dead network connection, although it is probably a correct change. I suppose giving the loop even more reasons to return -ERANGE wasn't going to be helpful. - -- Kevin Winchester -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHP5KXKPGFQbiQ3tQRAilbAJ9h3qtO9sb9+ctVU0pxzCBjysy06QCdE1Wd M5V3+0BWyn04p0UeUq/KSlw= =663t -END PGP SIGNATURE- - 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-rc2-mm1 -- strange apparent network failures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
> Kevin,
>
> Can you try this quick hack?
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index e57d1aa..4088610 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,7 +109,7 @@ out:
> kdata[i].permitted = pP.cap[i];
> kdata[i].inheritable = pI.cap[i];
> }
> - while (i < _LINUX_CAPABILITY_U32S) {
> + while (0 && (i < _LINUX_CAPABILITY_U32S)) {
> if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {
> /* Cannot represent w/ legacy structure */
> return -ERANGE;
>
Well, something went wrong with the patch - it has extra negative signs
in my mail reader, and on lkml, but now that I've hit reply and it's
been quoted, it looks fine in my mail client. So I have no idea what
went on.
However, I got around the problem by making the code change manually -
and my network connection is now working. Looking at the code being
bypassed:
if (pE.cap[i] || pP.cap[i] || pP.cap[i])
looks somewhat weird as it is testing the same condition twice. Should
it have been:
if (pE.cap[i] || pP.cap[i] || pI.cap[i])
?
I'm about to test that change instead of bypassing the loop, so I'll let
you know the results.
- --
Kevin Winchester
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP4xGKPGFQbiQ3tQRAooWAJ9c6exhOiD4VUZ04hS9z77/RmERUACfauTE
BV/JAexzlm2zSmG4laYi+HQ=
=IPkA
-END PGP SIGNATURE-
-
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-rc2-mm1 -- strange apparent network failures
On November 17, 2007 01:16:58 am Andrew Morgan wrote: > Hi, > > This warning is just saying that you might want to reconsider > recompiling your dhclient with a newer libcap - which has native support > for 64-bit capabilities. This is supposed to be informative, and not be > associated with any particular error. > > From your comments, you believe that this patch causes something in your > boot process to fail. Can you supply some detail about the version of > dhclient you are using? I'd like to understand exactly what it is doing > (via libcap). > > Thanks > The boot succeeds (and appears to bring initialize the network adapter properly - it autonegotiates a 100Mbps link speed), but the dhcp client is never able to get an address. However, applying the rc2-mm1 patch series up to just before: add-64-bit-capability-support-to-the-kernel.patch results in a working kernel. Applying just this patch causes the failure. To be sure, I also tried applying the above patch plus the following ones: add-64-bit-capability-support-to-the-kernel-checkpatch-fixes.patch add-64-bit-capability-support-to-the-kernel-fix.patch add-64-bit-capability-support-to-the-kernel-fix-fix.patch remove-unnecessary-include-from-include-linux-capabilityh.patch but the problem still occurs even with all of these. As to versions, I'm running Kubuntu gutsy, so I have the default: dhcp3-client 3.0.5-3ubuntu4 libcap11:1.10-14build1 packages installed. Let me know if you need any other information, or if you have a patch you would like tested. -- Kevin Winchester - 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-rc2-mm1 -- strange apparent network failures
On November 17, 2007 01:16:58 am Andrew Morgan wrote: Hi, This warning is just saying that you might want to reconsider recompiling your dhclient with a newer libcap - which has native support for 64-bit capabilities. This is supposed to be informative, and not be associated with any particular error. From your comments, you believe that this patch causes something in your boot process to fail. Can you supply some detail about the version of dhclient you are using? I'd like to understand exactly what it is doing (via libcap). Thanks The boot succeeds (and appears to bring initialize the network adapter properly - it autonegotiates a 100Mbps link speed), but the dhcp client is never able to get an address. However, applying the rc2-mm1 patch series up to just before: add-64-bit-capability-support-to-the-kernel.patch results in a working kernel. Applying just this patch causes the failure. To be sure, I also tried applying the above patch plus the following ones: add-64-bit-capability-support-to-the-kernel-checkpatch-fixes.patch add-64-bit-capability-support-to-the-kernel-fix.patch add-64-bit-capability-support-to-the-kernel-fix-fix.patch remove-unnecessary-include-from-include-linux-capabilityh.patch but the problem still occurs even with all of these. As to versions, I'm running Kubuntu gutsy, so I have the default: dhcp3-client 3.0.5-3ubuntu4 libcap11:1.10-14build1 packages installed. Let me know if you need any other information, or if you have a patch you would like tested. -- Kevin Winchester - 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-rc2-mm1 -- strange apparent network failures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
Kevin,
Can you try this quick hack?
diff --git a/kernel/capability.c b/kernel/capability.c
index e57d1aa..4088610 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -109,7 +109,7 @@ out:
kdata[i].permitted = pP.cap[i];
kdata[i].inheritable = pI.cap[i];
}
- while (i _LINUX_CAPABILITY_U32S) {
+ while (0 (i _LINUX_CAPABILITY_U32S)) {
if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {
/* Cannot represent w/ legacy structure */
return -ERANGE;
Well, something went wrong with the patch - it has extra negative signs
in my mail reader, and on lkml, but now that I've hit reply and it's
been quoted, it looks fine in my mail client. So I have no idea what
went on.
However, I got around the problem by making the code change manually -
and my network connection is now working. Looking at the code being
bypassed:
if (pE.cap[i] || pP.cap[i] || pP.cap[i])
looks somewhat weird as it is testing the same condition twice. Should
it have been:
if (pE.cap[i] || pP.cap[i] || pI.cap[i])
?
I'm about to test that change instead of bypassing the loop, so I'll let
you know the results.
- --
Kevin Winchester
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP4xGKPGFQbiQ3tQRAooWAJ9c6exhOiD4VUZ04hS9z77/RmERUACfauTE
BV/JAexzlm2zSmG4laYi+HQ=
=IPkA
-END PGP SIGNATURE-
-
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-rc2-mm1 -- strange apparent network failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Winchester wrote: Looking at the code being bypassed: if (pE.cap[i] || pP.cap[i] || pP.cap[i]) looks somewhat weird as it is testing the same condition twice. Should it have been: if (pE.cap[i] || pP.cap[i] || pI.cap[i]) ? I'm about to test that change instead of bypassing the loop, so I'll let you know the results. No, this still results in a dead network connection, although it is probably a correct change. I suppose giving the loop even more reasons to return -ERANGE wasn't going to be helpful. - -- Kevin Winchester -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHP5KXKPGFQbiQ3tQRAilbAJ9h3qtO9sb9+ctVU0pxzCBjysy06QCdE1Wd M5V3+0BWyn04p0UeUq/KSlw= =663t -END PGP SIGNATURE- - 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-rc2-mm1 -- strange apparent network failures
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
Kevin,
Can you try this quick hack?
diff --git a/kernel/capability.c b/kernel/capability.c
index e57d1aa..4088610 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -109,7 +109,7 @@ out:
kdata[i].permitted = pP.cap[i];
kdata[i].inheritable = pI.cap[i];
}
- while (i _LINUX_CAPABILITY_U32S) {
+ while (0 (i _LINUX_CAPABILITY_U32S)) {
if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {
/* Cannot represent w/ legacy structure */
return -ERANGE;
Oh, and the reason your patch turned up incorrect in my mailer and on
lkml seems to be the PGP signature. I didn't have your public key, so
my mail client just left the full PGP-signed text in, which includes
escaping of '-' characters. LKML must also ignore the signature. Once
I added your public key, the patch shows up correctly in my client at least.
(I guess everyone else probably knew this already...but at least I
learned something new today)
- --
Kevin Winchester
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP5QdKPGFQbiQ3tQRAqimAJwOSGDSM2wXeLbm+sBKehGf/haNpACfX7Cb
IALnPxwlgShR6Xb+XQclBro=
=xFUp
-END PGP SIGNATURE-
-
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-rc2-mm1 -- strange apparent network failures
On November 15, 2007 08:44:41 pm Andrew Morton wrote: > On Thu, 15 Nov 2007 20:28:29 -0400 > > Kevin Winchester <[EMAIL PROTECTED]> wrote: > > On November 15, 2007 06:02:09 am Andy Whitcroft wrote: > > I see this as well - the computer boots fine but no network. The only > > clues in the dmesg are: > > > > [ 294.097876] warning: process `dhclient' gets w/ old libcap > > [ 294.097893] warning: process `dhclient' sets w/ old libcap > > > > So I'll try backing up the patch series to before: > > > > add-64-bit-capability-support-to-the-kernel.patch > That's the winner. The changelog indicates that the patch is meant to keep compatibility with older userspace, so I guess it didn't quite keep as much compatibility as it wanted. I have no idea what I'm doing, but I'll take a look at the patch anyway... -- Kevin Winchester - 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-rc2-mm1 -- strange apparent network failures
On November 15, 2007 06:02:09 am Andy Whitcroft wrote: > When testing some of the later 2.6.24-rc2-mm1+hotfix combinations on three > of our test systems one job from each batch (1/4) failed. In each case the > machine appears to have booted normally all the way to a login: prompt. > However in the failed boots the networking though apparently initialised > completely and correctly (as far as I can tell from the console output), is > reported as not responding to ssh connections. The network interface seems > to have been initialised on the right port, and the ssh daemons started. > > Two of the machines are powerpc boxes, the other an older x86_64. > One machine is 4/4 in testing, just one. Most of the other machines are > still not able to compile this stack so do not contribute to our knowledge. > > Any ideas? > I see this as well - the computer boots fine but no network. The only clues in the dmesg are: [ 294.097876] warning: process `dhclient' gets w/ old libcap [ 294.097893] warning: process `dhclient' sets w/ old libcap So I'll try backing up the patch series to before: add-64-bit-capability-support-to-the-kernel.patch or so, and see if that's the problem. If anyone has any other ideas, let me know. -- Kevin Winchester - 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-rc2-mm1 -- strange apparent network failures
On November 15, 2007 06:02:09 am Andy Whitcroft wrote: When testing some of the later 2.6.24-rc2-mm1+hotfix combinations on three of our test systems one job from each batch (1/4) failed. In each case the machine appears to have booted normally all the way to a login: prompt. However in the failed boots the networking though apparently initialised completely and correctly (as far as I can tell from the console output), is reported as not responding to ssh connections. The network interface seems to have been initialised on the right port, and the ssh daemons started. Two of the machines are powerpc boxes, the other an older x86_64. One machine is 4/4 in testing, just one. Most of the other machines are still not able to compile this stack so do not contribute to our knowledge. Any ideas? I see this as well - the computer boots fine but no network. The only clues in the dmesg are: [ 294.097876] warning: process `dhclient' gets w/ old libcap [ 294.097893] warning: process `dhclient' sets w/ old libcap So I'll try backing up the patch series to before: add-64-bit-capability-support-to-the-kernel.patch or so, and see if that's the problem. If anyone has any other ideas, let me know. -- Kevin Winchester - 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-rc2-mm1 -- strange apparent network failures
On November 15, 2007 08:44:41 pm Andrew Morton wrote: On Thu, 15 Nov 2007 20:28:29 -0400 Kevin Winchester [EMAIL PROTECTED] wrote: On November 15, 2007 06:02:09 am Andy Whitcroft wrote: I see this as well - the computer boots fine but no network. The only clues in the dmesg are: [ 294.097876] warning: process `dhclient' gets w/ old libcap [ 294.097893] warning: process `dhclient' sets w/ old libcap So I'll try backing up the patch series to before: add-64-bit-capability-support-to-the-kernel.patch That's the winner. The changelog indicates that the patch is meant to keep compatibility with older userspace, so I guess it didn't quite keep as much compatibility as it wanted. I have no idea what I'm doing, but I'll take a look at the patch anyway... -- Kevin Winchester - 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: mm snapshot broken-out-2007-11-13-04-14.tar.gz uploaded
On November 13, 2007 08:15:41 am [EMAIL PROTECTED] wrote: > The mm snapshot broken-out-2007-11-13-04-14.tar.gz has been uploaded to > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-13- >04-14.tar.gz > > It contains the following patches against 2.6.24-rc2: > How exactly do I go about trying out this snapshot? I did the following: - exported 2.6.24-rc2 from my cloned git tree to a separate folder - installed quilt - extracted the patches to the "patches" directory at the top level of the 2.6.24-rc2 tree - copied the list of patches from your mail into a "series" file which I placed in the "patches" directory - ran "quilt push -a" The result was that all of the patches seem to have been applied, but there were many offsets and at least one fuzzed patch. Should they have applied cleanly? Is quilt the way I am supposed to be applying these patches? Is there a reason that there is no "series" file in the archive with the patches? Slightly confused, -- Kevin Winchester - 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: mm snapshot broken-out-2007-11-13-04-14.tar.gz uploaded
On November 13, 2007 08:15:41 am [EMAIL PROTECTED] wrote: The mm snapshot broken-out-2007-11-13-04-14.tar.gz has been uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-13- 04-14.tar.gz It contains the following patches against 2.6.24-rc2: snip How exactly do I go about trying out this snapshot? I did the following: - exported 2.6.24-rc2 from my cloned git tree to a separate folder - installed quilt - extracted the patches to the patches directory at the top level of the 2.6.24-rc2 tree - copied the list of patches from your mail into a series file which I placed in the patches directory - ran quilt push -a The result was that all of the patches seem to have been applied, but there were many offsets and at least one fuzzed patch. Should they have applied cleanly? Is quilt the way I am supposed to be applying these patches? Is there a reason that there is no series file in the archive with the patches? Slightly confused, -- Kevin Winchester - 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: -mm merge plans for 2.6.23
On Tue, 10 Jul 2007 18:14:19 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> > wrote: > > > We all know swap prefetch has been tested out the wazoo since Moses was a > > little boy, is compile-time and runtime selectable, and gives an important > > and quantifiable performance increase to desktop systems. > > Always interested. Please provide us more details on your usage and > testing of that code. Amount of memory, workload, observed results, > etc? > I only have 512 MB of memory on my Athlon64 desktop box, and I switch between -mm and mainline kernels regularly. I have noticed that -mm is always much more responsive, especially first thing in the morning. I believe this has been due to the new schedulers in -mm (because I notice an improvement in mainline now that CFS has been merged), as well as swap prefetch. I haven't tested swap prefetch alone to know for sure, but it seems pretty likely. My workload is compiling kernels, with sylpheed, pidgin and firefox[1] open, and sometimes MonoDevelop if I want to slow my system to a crawl. I will be getting another 512 MB of RAM at Christmas time, but from the other reports, it seems that swap prefetch will still be useful. [1] Is there a graphical browser for linux that doesn't suck huge amounts of RAM? -- Kevin Winchester pgptNkcWRn6hg.pgp Description: PGP signature
Re: [ck] Re: -mm merge plans for 2.6.23
On Tue, 10 Jul 2007 18:14:19 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 11 Jul 2007 11:02:56 +1000 Matthew Hawkins [EMAIL PROTECTED] wrote: We all know swap prefetch has been tested out the wazoo since Moses was a little boy, is compile-time and runtime selectable, and gives an important and quantifiable performance increase to desktop systems. Always interested. Please provide us more details on your usage and testing of that code. Amount of memory, workload, observed results, etc? I only have 512 MB of memory on my Athlon64 desktop box, and I switch between -mm and mainline kernels regularly. I have noticed that -mm is always much more responsive, especially first thing in the morning. I believe this has been due to the new schedulers in -mm (because I notice an improvement in mainline now that CFS has been merged), as well as swap prefetch. I haven't tested swap prefetch alone to know for sure, but it seems pretty likely. My workload is compiling kernels, with sylpheed, pidgin and firefox[1] open, and sometimes MonoDevelop if I want to slow my system to a crawl. I will be getting another 512 MB of RAM at Christmas time, but from the other reports, it seems that swap prefetch will still be useful. [1] Is there a graphical browser for linux that doesn't suck huge amounts of RAM? -- Kevin Winchester pgptNkcWRn6hg.pgp Description: PGP signature
Re: 2.6.22-rc4-mm2 -- ipw2200 -- SIOCSIFADDR: No buffer space available
On 07/06/07, Miles Lane <[EMAIL PROTECTED]> wrote: Hi Andrew, This might be some problem with my kernel configuration. I added: CONFIG_BONDING=y # dhclient eth1 There is already a pid file /var/run/dhclient.pid with pid 134993416 Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ SIOCSIFADDR: No buffer space available Listening on LPF/eth1/00:12:f0:5e:db:2f Sending on LPF/eth1/00:12:f0:5e:db:2f Sending on Socket/fallback DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.1.1 DHCPREQUEST on eth1 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 SIOCSIFADDR: No buffer space available SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCADDRT: Network is unreachable bound to 192.168.1.2 -- renewal in 2993 seconds. # ping www.yahoo.com ping: unknown host www.yahoo.com Any suggestions what to try now? I'll go ahead and turn off the bonding option and see if that helps. I was seeing this same error last night on my via-velocity based ethernet interface. I chalked it up to some config mistake on my part, but I guess there might be more to it. Whatever it is, it doesn't seem to be specific to the ipw2200 driver. -- Kevin Winchester - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2 -- ipw2200 -- SIOCSIFADDR: No buffer space available
On 07/06/07, Miles Lane [EMAIL PROTECTED] wrote: Hi Andrew, This might be some problem with my kernel configuration. I added: CONFIG_BONDING=y # dhclient eth1 There is already a pid file /var/run/dhclient.pid with pid 134993416 Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ SIOCSIFADDR: No buffer space available Listening on LPF/eth1/00:12:f0:5e:db:2f Sending on LPF/eth1/00:12:f0:5e:db:2f Sending on Socket/fallback DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.1.1 DHCPREQUEST on eth1 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 SIOCSIFADDR: No buffer space available SIOCSIFNETMASK: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCADDRT: Network is unreachable bound to 192.168.1.2 -- renewal in 2993 seconds. # ping www.yahoo.com ping: unknown host www.yahoo.com Any suggestions what to try now? I'll go ahead and turn off the bonding option and see if that helps. I was seeing this same error last night on my via-velocity based ethernet interface. I chalked it up to some config mistake on my part, but I guess there might be more to it. Whatever it is, it doesn't seem to be specific to the ipw2200 driver. -- Kevin Winchester - 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: x86 setup rewrite tree ready for flamage^W review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: > Kevin Winchester wrote: >> Not sure if you were looking for testing, but I fuzzed it to apply to >> 2.6.21-git and gave it a spin. Worked just like a normal boot (which I >> assume was the point). > > That would be the point, yes :) Looking for breakage in video mode > detection, memory detection, and APM are probably the trickiest areas. > > -hpa > Video mode detection (including "scan") seemed to work just the same as before. As for memory detection, my 512M x86-64 UP system is probably not what you had in mind, and I don't really know what goes on for APM or how to test it. As well, I've been looking through the actual code, and even with my very limited experience with x86 assembler and operating systems, I now at least have an idea of what is going on. So switching to C for as much of the code as possible seems like the right idea if you want to make it easier for new people to get involved in that area of the kernel. Kevin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRl1CKPGFQbiQ3tQRAuEcAJ93zlfNzB7YipLHgvkQP3Jrtjh0EwCfSRQ5 9emaZMVvJsuXMs1ifO4KWkY= =G4zx -END PGP SIGNATURE- - 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: x86 setup rewrite tree ready for flamage^W review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: Kevin Winchester wrote: Not sure if you were looking for testing, but I fuzzed it to apply to 2.6.21-git and gave it a spin. Worked just like a normal boot (which I assume was the point). That would be the point, yes :) Looking for breakage in video mode detection, memory detection, and APM are probably the trickiest areas. -hpa Video mode detection (including scan) seemed to work just the same as before. As for memory detection, my 512M x86-64 UP system is probably not what you had in mind, and I don't really know what goes on for APM or how to test it. As well, I've been looking through the actual code, and even with my very limited experience with x86 assembler and operating systems, I now at least have an idea of what is going on. So switching to C for as much of the code as possible seems like the right idea if you want to make it easier for new people to get involved in that area of the kernel. Kevin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRl1CKPGFQbiQ3tQRAuEcAJ93zlfNzB7YipLHgvkQP3Jrtjh0EwCfSRQ5 9emaZMVvJsuXMs1ifO4KWkY= =G4zx -END PGP SIGNATURE- - 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: x86 setup rewrite tree ready for flamage^W review
H. Peter Anvin wrote: > Hello all, > > I believe the x86 setup tree is now finished. I will turn it into a > "clean patchset" later this week, but I wanted to get flamed^W feedback > on it first. > > The git tree is at: > > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary > git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git > ... > > ... and a flat patch at ... > > http://www.kernel.org/pub/linux/kernel/people/hpa/newsetup-36f021b5.patch > > -hpa > - > 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/ > > > Not sure if you were looking for testing, but I fuzzed it to apply to 2.6.21-git and gave it a spin. Worked just like a normal boot (which I assume was the point). [0.00] Linux version 2.6.21-g0a3fd051-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #9 PREEMPT Fri May 11 20:50:02 ADT 2007 [0.00] Command line: root=/dev/sda3 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1fef (usable) [0.00] BIOS-e820: 1fef - 1fef3000 (ACPI NVS) [0.00] BIOS-e820: 1fef3000 - 1ff0 (ACPI data) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130800) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F77D0, 0014 (r0 VIAK8T) [0.00] ACPI: RSDT 1FEF3040, 0034 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: FACP 1FEF30C0, 0074 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: DSDT 1FEF3180, 4F8A (r1 VIAK8T AWRDACPI 1000 MSFT 10E) [0.00] ACPI: FACS 1FEF, 0040 [0.00] ACPI: BOOT 1FEF8180, 0028 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: SSDT 1FEF82C0, 00B5 (r1 PTLTD POWERNOW1 LTP1) [0.00] ACPI: APIC 1FEF8200, 0068 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130800) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 130800 [0.00] On node 0 totalpages: 130703 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1356 pages reserved [0.00] DMA zone: 2587 pages, LIFO batch:0 [0.00] DMA32 zone: 1732 pages used for memmap [0.00] DMA32 zone: 124972 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x4008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [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 low 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] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI resources starting at 2000 (gap: 1ff0:ded0) [0.00] Built 1 zonelists. Total pages: 127559 [0.00] Kernel command line: root=/dev/sda3 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 2048 (order: 11, 16384 bytes) [ 13.327158] time.c: Detected 1838.853 MHz processor. [ 13.328328] Console: colour VGA+ 80x25 [ 13.331709] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [ 13.332048] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [ 13.332193] Checking aperture... [ 13.332264] CPU 0: aperture @ e000 size 128 MB [ 13.337619] Memory: 509000k/523200k available (3246k kernel code, 13476k reserved, 1225k
Re: x86 setup rewrite tree ready for flamage^W review
H. Peter Anvin wrote: Hello all, I believe the x86 setup tree is now finished. I will turn it into a clean patchset later this week, but I wanted to get flamed^W feedback on it first. The git tree is at: http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git ... ... and a flat patch at ... http://www.kernel.org/pub/linux/kernel/people/hpa/newsetup-36f021b5.patch -hpa - 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/ Not sure if you were looking for testing, but I fuzzed it to apply to 2.6.21-git and gave it a spin. Worked just like a normal boot (which I assume was the point). [0.00] Linux version 2.6.21-g0a3fd051-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #9 PREEMPT Fri May 11 20:50:02 ADT 2007 [0.00] Command line: root=/dev/sda3 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1fef (usable) [0.00] BIOS-e820: 1fef - 1fef3000 (ACPI NVS) [0.00] BIOS-e820: 1fef3000 - 1ff0 (ACPI data) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130800) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F77D0, 0014 (r0 VIAK8T) [0.00] ACPI: RSDT 1FEF3040, 0034 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: FACP 1FEF30C0, 0074 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: DSDT 1FEF3180, 4F8A (r1 VIAK8T AWRDACPI 1000 MSFT 10E) [0.00] ACPI: FACS 1FEF, 0040 [0.00] ACPI: BOOT 1FEF8180, 0028 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: SSDT 1FEF82C0, 00B5 (r1 PTLTD POWERNOW1 LTP1) [0.00] ACPI: APIC 1FEF8200, 0068 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130800) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 130800 [0.00] On node 0 totalpages: 130703 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1356 pages reserved [0.00] DMA zone: 2587 pages, LIFO batch:0 [0.00] DMA32 zone: 1732 pages used for memmap [0.00] DMA32 zone: 124972 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x4008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [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 low 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] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI resources starting at 2000 (gap: 1ff0:ded0) [0.00] Built 1 zonelists. Total pages: 127559 [0.00] Kernel command line: root=/dev/sda3 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 2048 (order: 11, 16384 bytes) [ 13.327158] time.c: Detected 1838.853 MHz processor. [ 13.328328] Console: colour VGA+ 80x25 [ 13.331709] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [ 13.332048] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [ 13.332193] Checking aperture... [ 13.332264] CPU 0: aperture @ e000 size 128 MB [ 13.337619] Memory: 509000k/523200k available (3246k kernel code, 13476k reserved, 1225k data, 184k init) [ 13.337752]
