Re: Linux & FAT32 label
On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote: > On Thursday 12 October 2017 12:13:11 Karel Zak wrote: > > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote: > > > > The best for me is to keep blkid output backwardly compatible as much > > > > as possible :-) > > > > > > Backward compatibility is a good reason. But what with situation when > > > interoperability with other systems (e.g. Windows) does not work as > > > expected? > > > > Then... I'm ready to do the changes to keep interoperability with the > > rest of the universe. It's the same situation as with UDF, you know... > > Apparently situation is not same as with UDF. For UDF we have > specification and basically all known UDF implementation by me were > compatible how to treat label except blkid (which read different think). > > For FAT32 we have 3 different linux implementations (blkid, fatlabel, > mlabel) and every one is slightly different in reading label (see > results sent in previous emails). > > What is first needed to know if implementations are willing to change to > be more or less same. And then decide what we want to change. > > Andreas, as fatlabel maintainer, what do you think about it? > > If you want, I can prepare patches for blkid and fatlabel to mimic > behavior written in proposed solution. But I think it does not make > sense to change just one Linux tool... I was worried that there might be some scripts or programs that expect the "NO NAME" output for unlabeled volumes from fatlabel. At least there does not appear anything like that judging from a few searches on codesearch.debian.net. Not that there's a guaranteed "NO NAME" on unlabeled filesystems, in an unlikely case the boot sector label field might be missing altogether. So far I think I will change fatlabel to chop off trailing white space when printing and have it interpret no rootdir label + boot sector label == NO NAME as no label. The other thing is completely ignoring the boot sector label, which I could have as a mode enabled by command line switch or environmental variable, or just outright make it the default. I'm not decided yet. Another problem is whether to also ignore boot sector on setting label. Otherwise the sequence: "set label on Linux" (both root and boot) "change label on Windows" (root label is changed) "remove label on Windows" (root label is deleted) "view label on Linux" (no root label, use boot label) resurrects an old label.
Re: Linux & FAT32 label
On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote: > On Thursday 12 October 2017 12:13:11 Karel Zak wrote: > > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote: > > > > The best for me is to keep blkid output backwardly compatible as much > > > > as possible :-) > > > > > > Backward compatibility is a good reason. But what with situation when > > > interoperability with other systems (e.g. Windows) does not work as > > > expected? > > > > Then... I'm ready to do the changes to keep interoperability with the > > rest of the universe. It's the same situation as with UDF, you know... > > Apparently situation is not same as with UDF. For UDF we have > specification and basically all known UDF implementation by me were > compatible how to treat label except blkid (which read different think). > > For FAT32 we have 3 different linux implementations (blkid, fatlabel, > mlabel) and every one is slightly different in reading label (see > results sent in previous emails). > > What is first needed to know if implementations are willing to change to > be more or less same. And then decide what we want to change. > > Andreas, as fatlabel maintainer, what do you think about it? > > If you want, I can prepare patches for blkid and fatlabel to mimic > behavior written in proposed solution. But I think it does not make > sense to change just one Linux tool... I was worried that there might be some scripts or programs that expect the "NO NAME" output for unlabeled volumes from fatlabel. At least there does not appear anything like that judging from a few searches on codesearch.debian.net. Not that there's a guaranteed "NO NAME" on unlabeled filesystems, in an unlikely case the boot sector label field might be missing altogether. So far I think I will change fatlabel to chop off trailing white space when printing and have it interpret no rootdir label + boot sector label == NO NAME as no label. The other thing is completely ignoring the boot sector label, which I could have as a mode enabled by command line switch or environmental variable, or just outright make it the default. I'm not decided yet. Another problem is whether to also ignore boot sector on setting label. Otherwise the sequence: "set label on Linux" (both root and boot) "change label on Windows" (root label is changed) "remove label on Windows" (root label is deleted) "view label on Linux" (no root label, use boot label) resurrects an old label.
Re: Linux & FAT32 label
On Mon, Oct 16, 2017 at 12:04:50AM +0200, Pali Rohár wrote: > On Sunday 15 October 2017 08:59:01 Pavel Machek wrote: > > Hi! > > > > > Based on results I would propose following unification: > > > > > ... > > > 4. Prefer label from the root directory. If there is none entry (means > > >there is also no erased entry), then read label from root sector. > > > > > >--> Reason: Windows XP and mlabel ignores what is written in boot > > >sector. Windows XP even do not update boot sector, so label > > >stored in boot sector is incorrect after any change done by > > >Windows XP. > > > > > >But due to compatibility with older dosfslabel, which stores > > >label only to boot sector, there is need for some fallback. Due > > >to point 1. the best seems to be to process also erased label in > > >root directory (marked with leading 0xE5) and fallback to boot > > >sector only in case label in root directory is missing. > > > > > > What do you think about it? > > > > 4. seems dangerous. Assume we have "OLD" in boot sector and "0xe5-EW" in > > the directory > > entry. The label will change from to "OLD" when the directory entry > > is reused by > > "FOO.TXT", right? That seems surprising / dangerous. > > Hm... that is a good question what happen (I do not know). I think that > current situation when Windows XP show different label as Linux is also > _surprising_. > > Do you have a better idea what to do and how to handle this situation? I have been saying this, a deleted directory entry has no valid contents and its existence should not be considered meaningful. A Windows formatted FAT filesystem without label will have no root directory label entry and if an existing label is deleted, that deleted entry can be overwritten at any time. "Ignoring the presence of boot sector labels" is the only thing I see for practical Windows compatibility.
Re: Linux & FAT32 label
On Mon, Oct 16, 2017 at 12:04:50AM +0200, Pali Rohár wrote: > On Sunday 15 October 2017 08:59:01 Pavel Machek wrote: > > Hi! > > > > > Based on results I would propose following unification: > > > > > ... > > > 4. Prefer label from the root directory. If there is none entry (means > > >there is also no erased entry), then read label from root sector. > > > > > >--> Reason: Windows XP and mlabel ignores what is written in boot > > >sector. Windows XP even do not update boot sector, so label > > >stored in boot sector is incorrect after any change done by > > >Windows XP. > > > > > >But due to compatibility with older dosfslabel, which stores > > >label only to boot sector, there is need for some fallback. Due > > >to point 1. the best seems to be to process also erased label in > > >root directory (marked with leading 0xE5) and fallback to boot > > >sector only in case label in root directory is missing. > > > > > > What do you think about it? > > > > 4. seems dangerous. Assume we have "OLD" in boot sector and "0xe5-EW" in > > the directory > > entry. The label will change from to "OLD" when the directory entry > > is reused by > > "FOO.TXT", right? That seems surprising / dangerous. > > Hm... that is a good question what happen (I do not know). I think that > current situation when Windows XP show different label as Linux is also > _surprising_. > > Do you have a better idea what to do and how to handle this situation? I have been saying this, a deleted directory entry has no valid contents and its existence should not be considered meaningful. A Windows formatted FAT filesystem without label will have no root directory label entry and if an existing label is deleted, that deleted entry can be overwritten at any time. "Ignoring the presence of boot sector labels" is the only thing I see for practical Windows compatibility.
Re: [REGRESSION] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Thu, Jul 17, 2014 at 10:31:37AM +0200, Jan Kara wrote: > On Wed 16-07-14 23:34:08, Andreas Bombe wrote: > > On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote: > > > On Sun 29-06-14 00:50:50, Andreas Bombe wrote: > > > > None of the post 3.15 kernel boot for me. They all hang at the GRUB > > > > screen telling me it loaded and started the kernel, but the kernel > > > > itself stops before it prints anything (or even replaces the GRUB > > > > background graphics). > > > > > > > > I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 "printk: > > > > enable interrupts before calling console_trylock_for_printk()". > > > > Reverting that patch on the latest kernel (git 24b414d5a7) allows me to > > > > boot normally. I fixed the conflict in the revert by leaving in the "if > > > > (in_sched) return printed_len;". > > > > > > > > I have the "early printk via the EFI framebuffer" option enabled, > > > > disabling it made no difference however. > > > Thanks for report. I've been on vacation so I'm replying with a delay. I > > > believe this is one of the issues where this patch just uncovers > > > underlying > > > problem - I belive lockdep tries to report some locking issue in console > > > driver code (this patch increased lockdep coverage of console driver code) > > > however we are holding some locks in printk code which make lockdep > > > deadlock. Can you try running with the attached patch? > > > > EUNABLE > > > > You forgot to attach a patch. > Bah, sorry. Attaching now. I don't see anything in /sys/kernel/debug/tracing/trace_pipe or .../trace (besides the header) with your patch applied. In case you meant to test it with the problematic printk change, I also tried with the revert reverted. That still hangs as before without any error report to see. I checked the kernel logs and there is also no lockdep report anywhere. I get the "trace_printk() being used" notice but nothing else of interest around there. Though the notice should mean trace_printk() was used at least once? -- 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: [REGRESSION] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Thu, Jul 17, 2014 at 10:31:37AM +0200, Jan Kara wrote: On Wed 16-07-14 23:34:08, Andreas Bombe wrote: On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote: On Sun 29-06-14 00:50:50, Andreas Bombe wrote: None of the post 3.15 kernel boot for me. They all hang at the GRUB screen telling me it loaded and started the kernel, but the kernel itself stops before it prints anything (or even replaces the GRUB background graphics). I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 printk: enable interrupts before calling console_trylock_for_printk(). Reverting that patch on the latest kernel (git 24b414d5a7) allows me to boot normally. I fixed the conflict in the revert by leaving in the if (in_sched) return printed_len;. I have the early printk via the EFI framebuffer option enabled, disabling it made no difference however. Thanks for report. I've been on vacation so I'm replying with a delay. I believe this is one of the issues where this patch just uncovers underlying problem - I belive lockdep tries to report some locking issue in console driver code (this patch increased lockdep coverage of console driver code) however we are holding some locks in printk code which make lockdep deadlock. Can you try running with the attached patch? EUNABLE You forgot to attach a patch. Bah, sorry. Attaching now. I don't see anything in /sys/kernel/debug/tracing/trace_pipe or .../trace (besides the header) with your patch applied. In case you meant to test it with the problematic printk change, I also tried with the revert reverted. That still hangs as before without any error report to see. I checked the kernel logs and there is also no lockdep report anywhere. I get the trace_printk() being used notice but nothing else of interest around there. Though the notice should mean trace_printk() was used at least once? -- 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: [REGRESSION] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote: > On Sun 29-06-14 00:50:50, Andreas Bombe wrote: > > None of the post 3.15 kernel boot for me. They all hang at the GRUB > > screen telling me it loaded and started the kernel, but the kernel > > itself stops before it prints anything (or even replaces the GRUB > > background graphics). > > > > I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 "printk: > > enable interrupts before calling console_trylock_for_printk()". > > Reverting that patch on the latest kernel (git 24b414d5a7) allows me to > > boot normally. I fixed the conflict in the revert by leaving in the "if > > (in_sched) return printed_len;". > > > > I have the "early printk via the EFI framebuffer" option enabled, > > disabling it made no difference however. > Thanks for report. I've been on vacation so I'm replying with a delay. I > believe this is one of the issues where this patch just uncovers underlying > problem - I belive lockdep tries to report some locking issue in console > driver code (this patch increased lockdep coverage of console driver code) > however we are holding some locks in printk code which make lockdep > deadlock. Can you try running with the attached patch? EUNABLE You forgot to attach a patch. -- 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: [REGRESSION] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Mon, Jul 14, 2014 at 10:35:27AM +0200, Jan Kara wrote: On Sun 29-06-14 00:50:50, Andreas Bombe wrote: None of the post 3.15 kernel boot for me. They all hang at the GRUB screen telling me it loaded and started the kernel, but the kernel itself stops before it prints anything (or even replaces the GRUB background graphics). I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 printk: enable interrupts before calling console_trylock_for_printk(). Reverting that patch on the latest kernel (git 24b414d5a7) allows me to boot normally. I fixed the conflict in the revert by leaving in the if (in_sched) return printed_len;. I have the early printk via the EFI framebuffer option enabled, disabling it made no difference however. Thanks for report. I've been on vacation so I'm replying with a delay. I believe this is one of the issues where this patch just uncovers underlying problem - I belive lockdep tries to report some locking issue in console driver code (this patch increased lockdep coverage of console driver code) however we are holding some locks in printk code which make lockdep deadlock. Can you try running with the attached patch? EUNABLE You forgot to attach a patch. -- 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: [REGRESSION] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Mon, Jun 30, 2014 at 01:20:30PM -0700, Andrew Morton wrote: > On Sun, 29 Jun 2014 00:50:50 +0200 Andreas Bombe wrote: > > > None of the post 3.15 kernel boot for me. They all hang at the GRUB > > screen telling me it loaded and started the kernel, but the kernel > > itself stops before it prints anything (or even replaces the GRUB > > background graphics). > > > > I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 "printk: > > enable interrupts before calling console_trylock_for_printk()". > > Reverting that patch on the latest kernel (git 24b414d5a7) allows me to > > boot normally. > > OK, thanks, I queued the below reversion. I'll hold off for a week or > two in case we come up with a fix. > > > I fixed the conflict in the revert by leaving in the "if > > (in_sched) return printed_len;". > > hm, that might have been buggy - we still need to the lockdep_on() and > local_irq_restore(). You're a victim of > someone-stuck-a-random-return-in-the-middle-of-a-function. To be honest, I just randomly picked one possible conflict resolution to confirm whether the revert actually helps. > Please review this and if possible, run-time test it? Against current > mainline. I've applied it (actually I picked the one from your patch series but they are identical I think) and it does boot. I'm writing this on the latest kernel + your revert. -- 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: [REGRESSION] Boot hang with 939f04bec printk: enable interrupts before calling console_trylock_for_printk()
On Mon, Jun 30, 2014 at 01:20:30PM -0700, Andrew Morton wrote: On Sun, 29 Jun 2014 00:50:50 +0200 Andreas Bombe a...@debian.org wrote: None of the post 3.15 kernel boot for me. They all hang at the GRUB screen telling me it loaded and started the kernel, but the kernel itself stops before it prints anything (or even replaces the GRUB background graphics). I bisected it down to 939f04bec1a4ef6ba4370b0f34b01decc844b1b1 printk: enable interrupts before calling console_trylock_for_printk(). Reverting that patch on the latest kernel (git 24b414d5a7) allows me to boot normally. OK, thanks, I queued the below reversion. I'll hold off for a week or two in case we come up with a fix. I fixed the conflict in the revert by leaving in the if (in_sched) return printed_len;. hm, that might have been buggy - we still need to the lockdep_on() and local_irq_restore(). You're a victim of someone-stuck-a-random-return-in-the-middle-of-a-function. To be honest, I just randomly picked one possible conflict resolution to confirm whether the revert actually helps. Please review this and if possible, run-time test it? Against current mainline. I've applied it (actually I picked the one from your patch series but they are identical I think) and it does boot. I'm writing this on the latest kernel + your revert. -- 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/
[Regression] process hangs due to "USB: EHCI: work around silicon bug in Intels EHCI controllers"
The named commit (6402c796d3) causes a process to hang indefinitely in usb_kill_urb(). Reverting it fixes the problem. The bug also prevents suspend/shutdown/reboot from completing, presumably due to the hanging process. (Cc'ing Stephen Warren because I only found his report after I bisected it myself. Do you also see a blocked process?) This is the hanging process on my system: [ 240.364085] INFO: task colord-sane:3619 blocked for more than 120 seconds. [ 240.364090] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.364093] colord-sane D 1388 0 3619 3602 0x [ 240.364099] 8801255cd818 0046 0296 81c11400 [ 240.364105] 8801255cd7c8 880127488000 8801255cdfd8 8801255cdfd8 [ 240.364112] 00013600 880127488000 8801255cd828 8801234536c0 [ 240.364118] Call Trace: [ 240.364127] [] schedule+0x65/0x67 [ 240.364132] [] usb_kill_urb+0xb5/0xd3 [ 240.364138] [] ? bit_waitqueue+0x7a/0x7a [ 240.364143] [] usb_start_wait_urb+0xb2/0x173 [ 240.364148] [] usb_control_msg+0xd0/0x102 [ 240.364152] [] ? usb_get_status+0x3d/0xb0 [ 240.364158] [] ? kmem_cache_alloc_trace+0x4b/0xc9 [ 240.364163] [] ? _raw_spin_unlock_irqrestore+0x3f/0x6e [ 240.364167] [] usb_get_status+0x84/0xb0 [ 240.364172] [] ? _raw_spin_unlock_irqrestore+0x60/0x6e [ 240.364177] [] usb_port_resume+0x37c/0x5b4 [ 240.364183] [] ? mark_held_locks+0x55/0x99 [ 240.364187] [] ? _raw_spin_unlock_irq+0x2d/0x5a [ 240.364193] [] generic_resume+0x1c/0x1e [ 240.364197] [] usb_resume_both+0x94/0x106 [ 240.364202] [] ? usb_runtime_suspend+0x5d/0x5d [ 240.364206] [] usb_runtime_resume+0x1a/0x1c [ 240.364211] [] __rpm_callback+0x34/0x5b [ 240.364216] [] rpm_callback+0x56/0x79 [ 240.364220] [] rpm_resume+0x38a/0x4a7 [ 240.364225] [] ? _raw_spin_lock_irqsave+0x51/0x5c [ 240.364230] [] ? __pm_runtime_resume+0x5d/0x88 [ 240.364234] [] __pm_runtime_resume+0x6b/0x88 [ 240.364239] [] usb_autoresume_device+0x20/0x3f [ 240.364244] [] usbdev_open+0xc7/0x245 [ 240.364249] [] chrdev_open+0x130/0x15b [ 240.364254] [] ? lg_local_unlock+0x3f/0x5e [ 240.364259] [] ? cdev_put+0x26/0x26 [ 240.364264] [] do_dentry_open.isra.17+0x16b/0x211 [ 240.364268] [] finish_open+0x21/0x2d [ 240.364273] [] do_last.isra.59+0x7dc/0x962 [ 240.364278] [] ? inode_permission+0x45/0x47 [ 240.364282] [] ? link_path_walk+0xc2/0x43e [ 240.364287] [] path_openat.isra.60+0xc5/0x304 [ 240.364292] [] do_filp_open+0x38/0x86 [ 240.364297] [] ? spin_unlock+0x9/0xb [ 240.364302] [] ? __alloc_fd+0xf3/0x104 [ 240.364307] [] do_sys_open+0x6c/0xf9 [ 240.364311] [] sys_open+0x21/0x23 [ 240.364316] [] system_call_fastpath+0x1a/0x1f [ 240.364319] INFO: lockdep is turned off. I tested my USB hardware with Alan's patch/program and it is susceptible to the bug the problematic commit tries to work around, my hardware is: 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci -- 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/
[Regression] process hangs due to USB: EHCI: work around silicon bug in Intels EHCI controllers
The named commit (6402c796d3) causes a process to hang indefinitely in usb_kill_urb(). Reverting it fixes the problem. The bug also prevents suspend/shutdown/reboot from completing, presumably due to the hanging process. (Cc'ing Stephen Warren because I only found his report after I bisected it myself. Do you also see a blocked process?) This is the hanging process on my system: [ 240.364085] INFO: task colord-sane:3619 blocked for more than 120 seconds. [ 240.364090] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.364093] colord-sane D 1388 0 3619 3602 0x [ 240.364099] 8801255cd818 0046 0296 81c11400 [ 240.364105] 8801255cd7c8 880127488000 8801255cdfd8 8801255cdfd8 [ 240.364112] 00013600 880127488000 8801255cd828 8801234536c0 [ 240.364118] Call Trace: [ 240.364127] [81685af0] schedule+0x65/0x67 [ 240.364132] [8141a235] usb_kill_urb+0xb5/0xd3 [ 240.364138] [8109713a] ? bit_waitqueue+0x7a/0x7a [ 240.364143] [8141aa37] usb_start_wait_urb+0xb2/0x173 [ 240.364148] [8141ad21] usb_control_msg+0xd0/0x102 [ 240.364152] [8141ae07] ? usb_get_status+0x3d/0xb0 [ 240.364158] [8114fb80] ? kmem_cache_alloc_trace+0x4b/0xc9 [ 240.364163] [81686ce2] ? _raw_spin_unlock_irqrestore+0x3f/0x6e [ 240.364167] [8141ae4e] usb_get_status+0x84/0xb0 [ 240.364172] [81686d03] ? _raw_spin_unlock_irqrestore+0x60/0x6e [ 240.364177] [8141474c] usb_port_resume+0x37c/0x5b4 [ 240.364183] [810c372a] ? mark_held_locks+0x55/0x99 [ 240.364187] [81686d3e] ? _raw_spin_unlock_irq+0x2d/0x5a [ 240.364193] [81424794] generic_resume+0x1c/0x1e [ 240.364197] [8141cd94] usb_resume_both+0x94/0x106 [ 240.364202] [8141defb] ? usb_runtime_suspend+0x5d/0x5d [ 240.364206] [8141df15] usb_runtime_resume+0x1a/0x1c [ 240.364211] [813a85bd] __rpm_callback+0x34/0x5b [ 240.364216] [813a863a] rpm_callback+0x56/0x79 [ 240.364220] [813a960b] rpm_resume+0x38a/0x4a7 [ 240.364225] [816867a8] ? _raw_spin_lock_irqsave+0x51/0x5c [ 240.364230] [813a9921] ? __pm_runtime_resume+0x5d/0x88 [ 240.364234] [813a992f] __pm_runtime_resume+0x6b/0x88 [ 240.364239] [8141d7ad] usb_autoresume_device+0x20/0x3f [ 240.364244] [814244f3] usbdev_open+0xc7/0x245 [ 240.364249] [8115d14c] chrdev_open+0x130/0x15b [ 240.364254] [8109d115] ? lg_local_unlock+0x3f/0x5e [ 240.364259] [8115d01c] ? cdev_put+0x26/0x26 [ 240.364264] [81158182] do_dentry_open.isra.17+0x16b/0x211 [ 240.364268] [81158249] finish_open+0x21/0x2d [ 240.364273] [81164e3e] do_last.isra.59+0x7dc/0x962 [ 240.364278] [81162c32] ? inode_permission+0x45/0x47 [ 240.364282] [81162cf6] ? link_path_walk+0xc2/0x43e [ 240.364287] [81165089] path_openat.isra.60+0xc5/0x304 [ 240.364292] [811655c7] do_filp_open+0x38/0x86 [ 240.364297] [8116f05a] ? spin_unlock+0x9/0xb [ 240.364302] [8116fcab] ? __alloc_fd+0xf3/0x104 [ 240.364307] [81158eb6] do_sys_open+0x6c/0xf9 [ 240.364311] [81158f64] sys_open+0x21/0x23 [ 240.364316] [8168d286] system_call_fastpath+0x1a/0x1f [ 240.364319] INFO: lockdep is turned off. I tested my USB hardware with Alan's patch/program and it is susceptible to the bug the problematic commit tries to work around, my hardware is: 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin C routed to IRQ 18 Region 0: Memory at fe8ffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] Vendor Specific Information: Len=06 ? Kernel driver in use: ehci-pci -- 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: radeon causing sleeping function called from invalid context
On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote: > On (01/12/13 20:27), Dave Jones wrote: > > BUG: sleeping function called from invalid context at mm/slub.c:925 > > in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg > > INFO: lockdep is turned off. > > Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49 > > Call Trace: > > [] __might_sleep+0x141/0x200 > > [] kmem_cache_alloc_trace+0x4b/0x2a0 > > [] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm] > > [] radeon_move_blit.isra.4+0xf8/0x160 [radeon] > > [] radeon_bo_move+0xb0/0x1f0 [radeon] > > [] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm] > > [] ? get_parent_ip+0x11/0x50 > > [] ttm_bo_move_buffer+0x127/0x140 [ttm] > > [] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm] > > [] ttm_bo_validate+0xa2/0x120 [ttm] > > [] radeon_bo_list_validate+0x75/0x90 [radeon] > > [] radeon_cs_ioctl+0x582/0x950 [radeon] > > [] drm_ioctl+0x4d3/0x580 [drm] > > [] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon] > > [] do_vfs_ioctl+0x99/0x5a0 > > [] ? file_has_perm+0x97/0xb0 > > [] ? rcu_eqs_exit+0x65/0xb0 > > [] sys_ioctl+0x91/0xb0 > > [] tracesys+0xdd/0xe2 > > > > I see lots of these [mostly from page fault], the following one (quick and > dirty) works for me. Is that patch or any other fix being picked up? It's over three weeks now and I'm still seeing those BUGs with the latest 3.8-rc. -- 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: radeon causing sleeping function called from invalid context
On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote: On (01/12/13 20:27), Dave Jones wrote: BUG: sleeping function called from invalid context at mm/slub.c:925 in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg INFO: lockdep is turned off. Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49 Call Trace: [81087ad1] __might_sleep+0x141/0x200 [8119eddb] kmem_cache_alloc_trace+0x4b/0x2a0 [a0083fb3] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm] [a00c5418] radeon_move_blit.isra.4+0xf8/0x160 [radeon] [a00c5db0] radeon_bo_move+0xb0/0x1f0 [radeon] [a00820ed] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm] [8108dd51] ? get_parent_ip+0x11/0x50 [a0083307] ttm_bo_move_buffer+0x127/0x140 [ttm] [a008717d] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm] [a00833c2] ttm_bo_validate+0xa2/0x120 [ttm] [a00c6f45] radeon_bo_list_validate+0x75/0x90 [radeon] [a00dca22] radeon_cs_ioctl+0x582/0x950 [radeon] [a002e573] drm_ioctl+0x4d3/0x580 [drm] [a00dc4a0] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon] [811c49f9] do_vfs_ioctl+0x99/0x5a0 [812cd3d7] ? file_has_perm+0x97/0xb0 [81103715] ? rcu_eqs_exit+0x65/0xb0 [811c4f91] sys_ioctl+0x91/0xb0 [81695ad4] tracesys+0xdd/0xe2 I see lots of these [mostly from page fault], the following one (quick and dirty) works for me. Is that patch or any other fix being picked up? It's over three weeks now and I'm still seeing those BUGs with the latest 3.8-rc. -- 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/
[RFC PATCH] [SCSI] sd: When no media present ignore WCE in suspend/shutdown
When the WCE flag is set for a drive, sd_shutdown() and sd_suspend() try
to send a SYNCHRONIZE_CACHE command to that drive. This is not
meaningful when no media are present and causes errors with devices
where the media are the actual command processing devices, such as SATA
attached RDX docks where the removable cartridges contain hard disks.
In the RDX case, the WCE bit is set when a cartridge is inserted and not
reset when it is removed. Suspending the computer afterwards will not be
possible unless a cartridge is inserted since otherwise the
SYNCHRONIZE_CACHE command will fail causing sd_suspend() to return an
error.
Signed-off-by: Andreas Bombe
---
Ok, this patch makes the problem go away, but I'm not sure whether this
is right solution. I also don't know whether SATA RDX docks are sort of
a special case in this regard.
I can think of two other solutions:
1. Also skip the sd_start_stop_device() call. The device for the RDX
dock isn't managed so I can't test.
2. Clear the WCE flag when media are removed and leave sd_shutdown() /
sd_suspend() alone.
The final patch would then also be Cc: stable, I don't know how far back
this goes but at least 3.7 is affected.
drivers/scsi/sd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 7992635..723512e 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3048,7 +3048,7 @@ static void sd_shutdown(struct device *dev)
if (pm_runtime_suspended(dev))
goto exit;
- if (sdkp->WCE) {
+ if (sdkp->WCE && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
sd_sync_cache(sdkp);
}
@@ -3070,7 +3070,7 @@ static int sd_suspend(struct device *dev)
if (!sdkp)
return 0; /* this can happen */
- if (sdkp->WCE) {
+ if (sdkp->WCE && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
ret = sd_sync_cache(sdkp);
if (ret)
--
1.7.10.4
--
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/
[RFC PATCH] [SCSI] sd: When no media present ignore WCE in suspend/shutdown
When the WCE flag is set for a drive, sd_shutdown() and sd_suspend() try
to send a SYNCHRONIZE_CACHE command to that drive. This is not
meaningful when no media are present and causes errors with devices
where the media are the actual command processing devices, such as SATA
attached RDX docks where the removable cartridges contain hard disks.
In the RDX case, the WCE bit is set when a cartridge is inserted and not
reset when it is removed. Suspending the computer afterwards will not be
possible unless a cartridge is inserted since otherwise the
SYNCHRONIZE_CACHE command will fail causing sd_suspend() to return an
error.
Signed-off-by: Andreas Bombe a...@debian.org
---
Ok, this patch makes the problem go away, but I'm not sure whether this
is right solution. I also don't know whether SATA RDX docks are sort of
a special case in this regard.
I can think of two other solutions:
1. Also skip the sd_start_stop_device() call. The device for the RDX
dock isn't managed so I can't test.
2. Clear the WCE flag when media are removed and leave sd_shutdown() /
sd_suspend() alone.
The final patch would then also be Cc: stable, I don't know how far back
this goes but at least 3.7 is affected.
drivers/scsi/sd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 7992635..723512e 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3048,7 +3048,7 @@ static void sd_shutdown(struct device *dev)
if (pm_runtime_suspended(dev))
goto exit;
- if (sdkp-WCE) {
+ if (sdkp-WCE sdkp-media_present) {
sd_printk(KERN_NOTICE, sdkp, Synchronizing SCSI cache\n);
sd_sync_cache(sdkp);
}
@@ -3070,7 +3070,7 @@ static int sd_suspend(struct device *dev)
if (!sdkp)
return 0; /* this can happen */
- if (sdkp-WCE) {
+ if (sdkp-WCE sdkp-media_present) {
sd_printk(KERN_NOTICE, sdkp, Synchronizing SCSI cache\n);
ret = sd_sync_cache(sdkp);
if (ret)
--
1.7.10.4
--
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: [REGRESSION] Xorg doesn't like 4e8b14526 "time: Improve sanity checking of timekeeping inputs"
On Fri, Aug 31, 2012 at 10:43:42AM -0700, John Stultz wrote: > On 08/30/2012 09:05 PM, Andreas Bombe wrote: > >With that somewhat easy test I bisected it down to 4e8b14526 "time: > >Improve sanity checking of timekeeping inputs". The latest Linus git > >(155e36d40) with a revert of the bisected commit does not show the > >problem. > > Thanks so much for bisecting this down! > I'm guessing X is passing crazy large timespecs into select (via > WaitForSomething()) values that are catching on the ktime_t overflow > check in timespec_valid(). Previously these would be clamped to > KTIME_MAX (which basically is infinity) in the timer subsystem > before. > > So the issue is the patch in question is too strict in its > validation. We want to be strict on things like timekeeping inputs, > but for timers wait to infinity is still valid. > > The attached (sorry not inline, on the road) patch should fix this, > but could you verify it? (I'm running my testing concurrently) I'm running it now and it's looking good. I did the video test again and confirmed with strace that X was doing the giant timeout in select again, but this time without any errors. -- Andreas Bombe -- 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: [REGRESSION] Xorg doesn't like 4e8b14526 "time: Improve sanity checking of timekeeping inputs"
On Thu, Aug 30, 2012 at 09:25:52PM -0700, Linus Torvalds wrote:
> On Thu, Aug 30, 2012 at 9:05 PM, Andreas Bombe wrote:
> >
> > With that somewhat easy test I bisected it down to 4e8b14526 "time:
> > Improve sanity checking of timekeeping inputs". The latest Linus git
> > (155e36d40) with a revert of the bisected commit does not show the
> > problem.
>
> Ok, I guess we need to revert it. Although it might be interesting to
> add a WARN_ON_ONCE() for the case of timespec_valid() returning false,
> to just see exactly *where* that thing triggers. Could you do that? In
> fact, do it with separate WARN_ON_ONCE's for each of the reasons that
> function returns false, so that we also see which check it is that
> triggers. Ok?
It triggers on ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX).
Looking at some straces (I could have thought of that earlier…) X does
in fact call select with unreasonable timeouts:
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 2}) = 1 (in [24], left {0, 19988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 19000}) = 1 (in [24], left {0, 18988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 19000}) = 1 (in [24], left {0, 16804})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 16000}) = 1 (in [24], left {0, 15988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 25 26 27 28 29 30 31 32
33 34 35 37 38 39], NULL, NULL, {0, 16000}) = 1 (in [9], left {0, 3649})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 3000}) = 1 (in [24], left {0, 2988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 2000}) = 1 (in [24], left {0, 1988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 2000}) = 0 (Timeout)
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {18446744073709551, 615000}) = -1 EINVAL
(Invalid argument)
The time values are actually decreasing from 90 seconds to this. That
seconds value is actually (0ULL - 1) / 1000, so something is
decrementing the timeout beyond zero. I don't see how it could happen
directly in WaitForSomething in the X server sources[1], it's probably
in the BlockHandler callbacks somewhere.
Have to dig deeper to see if that is a long standing issue.
[1]
http://cgit.freedesktop.org/xorg/xserver/tree/os/WaitFor.c?h=mpx=xorg-server-1.12.3.902#n145
--
Andreas Bombe
--
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: [REGRESSION] Xorg doesn't like 4e8b14526 time: Improve sanity checking of timekeeping inputs
On Thu, Aug 30, 2012 at 09:25:52PM -0700, Linus Torvalds wrote:
On Thu, Aug 30, 2012 at 9:05 PM, Andreas Bombe a...@debian.org wrote:
With that somewhat easy test I bisected it down to 4e8b14526 time:
Improve sanity checking of timekeeping inputs. The latest Linus git
(155e36d40) with a revert of the bisected commit does not show the
problem.
Ok, I guess we need to revert it. Although it might be interesting to
add a WARN_ON_ONCE() for the case of timespec_valid() returning false,
to just see exactly *where* that thing triggers. Could you do that? In
fact, do it with separate WARN_ON_ONCE's for each of the reasons that
function returns false, so that we also see which check it is that
triggers. Ok?
It triggers on ((unsigned long long)ts-tv_sec = KTIME_SEC_MAX).
Looking at some straces (I could have thought of that earlier…) X does
in fact call select with unreasonable timeouts:
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 2}) = 1 (in [24], left {0, 19988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 19000}) = 1 (in [24], left {0, 18988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 19000}) = 1 (in [24], left {0, 16804})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 16000}) = 1 (in [24], left {0, 15988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 25 26 27 28 29 30 31 32
33 34 35 37 38 39], NULL, NULL, {0, 16000}) = 1 (in [9], left {0, 3649})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 3000}) = 1 (in [24], left {0, 2988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 2000}) = 1 (in [24], left {0, 1988})
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {0, 2000}) = 0 (Timeout)
| 17:46:55 select(256, [1 3 6 9 10 11 18 19 20 21 22 23 24 25 26 27 28 29 30 31
32 33 34 35 37 38 39], NULL, NULL, {18446744073709551, 615000}) = -1 EINVAL
(Invalid argument)
The time values are actually decreasing from 90 seconds to this. That
seconds value is actually (0ULL - 1) / 1000, so something is
decrementing the timeout beyond zero. I don't see how it could happen
directly in WaitForSomething in the X server sources[1], it's probably
in the BlockHandler callbacks somewhere.
Have to dig deeper to see if that is a long standing issue.
[1]
http://cgit.freedesktop.org/xorg/xserver/tree/os/WaitFor.c?h=mpxid=xorg-server-1.12.3.902#n145
--
Andreas Bombe
--
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: [REGRESSION] Xorg doesn't like 4e8b14526 time: Improve sanity checking of timekeeping inputs
On Fri, Aug 31, 2012 at 10:43:42AM -0700, John Stultz wrote: On 08/30/2012 09:05 PM, Andreas Bombe wrote: With that somewhat easy test I bisected it down to 4e8b14526 time: Improve sanity checking of timekeeping inputs. The latest Linus git (155e36d40) with a revert of the bisected commit does not show the problem. Thanks so much for bisecting this down! I'm guessing X is passing crazy large timespecs into select (via WaitForSomething()) values that are catching on the ktime_t overflow check in timespec_valid(). Previously these would be clamped to KTIME_MAX (which basically is infinity) in the timer subsystem before. So the issue is the patch in question is too strict in its validation. We want to be strict on things like timekeeping inputs, but for timers wait to infinity is still valid. The attached (sorry not inline, on the road) patch should fix this, but could you verify it? (I'm running my testing concurrently) I'm running it now and it's looking good. I did the video test again and confirmed with strace that X was doing the giant timeout in select again, but this time without any errors. -- Andreas Bombe -- 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/
[REGRESSION] Xorg doesn't like 4e8b14526 "time: Improve sanity checking of timekeeping inputs"
I have recently started to get problems with X simply shutting itself down and returning to the login screen. In the X logs I find: > [ 1492.936] > Fatal server error: > [ 1492.936] WaitForSomething(): select: Invalid argument No messages whatsoever is found in the kernel logs. This error happens randomly without any correlation to user input, but with a high likelihood (within a few minutes at most) when a video is playing. It doesn't matter if the video is in Flash in a browser window or in a video player playing a local file. With that somewhat easy test I bisected it down to 4e8b14526 "time: Improve sanity checking of timekeeping inputs". The latest Linus git (155e36d40) with a revert of the bisected commit does not show the problem. Video is Radeon HD 6950 with open source drivers. Xorg version is the one currently in Debian unstable (xserver-xorg-core: 2:1.12.3.902-1, xserver-xorg-video-radeon: 1:6.14.4-5, libdrm: 2.4.33-3). -- Andreas Bombe -- 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/
[REGRESSION] Xorg doesn't like 4e8b14526 time: Improve sanity checking of timekeeping inputs
I have recently started to get problems with X simply shutting itself down and returning to the login screen. In the X logs I find: [ 1492.936] Fatal server error: [ 1492.936] WaitForSomething(): select: Invalid argument No messages whatsoever is found in the kernel logs. This error happens randomly without any correlation to user input, but with a high likelihood (within a few minutes at most) when a video is playing. It doesn't matter if the video is in Flash in a browser window or in a video player playing a local file. With that somewhat easy test I bisected it down to 4e8b14526 time: Improve sanity checking of timekeeping inputs. The latest Linus git (155e36d40) with a revert of the bisected commit does not show the problem. Video is Radeon HD 6950 with open source drivers. Xorg version is the one currently in Debian unstable (xserver-xorg-core: 2:1.12.3.902-1, xserver-xorg-video-radeon: 1:6.14.4-5, libdrm: 2.4.33-3). -- Andreas Bombe -- 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: 2.4.5 and gcc v3 final
On Sun, Jun 24, 2001 at 01:33:51PM -0400, Horst von Brand wrote: > What gcc objects to is stuff like: > >"This is a nice long string > that just goes on > and on\n" > > which is illegal in C AFAIU. It does not object to: > >"This long string" >"spans several lines, " >"but legally.\n" But the first example contains three newlines, the second just one. A thing to keep in mind when going around fixing these multi line strings, explicit newlines have to be added. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Thu, Jun 21, 2001 at 02:21:18PM -0400, Rob Landley wrote: > Name one thing Microsoft actually invented. Other than Microsoft Bob. I remember there being a web page where all of Microsoft's "innovations" were listed and where they bought or stole it from. The only things that were really Microsoft's invention were, at that time, found to be a) the .ini config file format (which has spread outside of the MS world) and b) the annoying paper clip. Does anyone have the URL handy? Try finding that in a search engine... -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Thu, Jun 21, 2001 at 02:21:18PM -0400, Rob Landley wrote: Name one thing Microsoft actually invented. Other than Microsoft Bob. I remember there being a web page where all of Microsoft's innovations were listed and where they bought or stole it from. The only things that were really Microsoft's invention were, at that time, found to be a) the .ini config file format (which has spread outside of the MS world) and b) the annoying paper clip. Does anyone have the URL handy? Try finding that in a search engine... -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.4.5 and gcc v3 final
On Sun, Jun 24, 2001 at 01:33:51PM -0400, Horst von Brand wrote: What gcc objects to is stuff like: This is a nice long string that just goes on and on\n which is illegal in C AFAIU. It does not object to: This long string spans several lines, but legally.\n But the first example contains three newlines, the second just one. A thing to keep in mind when going around fixing these multi line strings, explicit newlines have to be added. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: a memory-related problem?
On Sun, Jun 17, 2001 at 02:37:03PM +0200, Ronald Bultje wrote: > system = p-II 400 MHz, 128 MB swap, 440BX (abit p6b) mainboard > memory is (133 MHz) SDRAM memory (running at 100 MHz) The question is, does it configure your SDRAMs correctly? I assume it's on auto config, then the BIOS has to figure out what timings to use for the RAMs by reading their SPD ROM. Problem 1: you run PC133 memory in PC100 configuration. Some PC133 DIMMs contain no configuration data for PC100, so they theoretically couldn't legally be run as PC100. They could be run using the PC133 config - not optimal, but should work. The BIOS has to figure that out, however. This problem is more likely to occur if you're using no-name RAMs instead of branded RAMs by a reputable vendor (you might not even have fully valid config data for PC133 in that case). Problem 2: your BIOS is broken and configures all DIMMs to the configuration values of the first, causing at least one to run with the wrong values, if they have different timing requirements. Given your problem (either DIMM works alone, two don't), this sounds like a more possible candidate. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: a memory-related problem?
On Sun, Jun 17, 2001 at 02:37:03PM +0200, Ronald Bultje wrote: system = p-II 400 MHz, 128 MB swap, 440BX (abit p6b) mainboard memory is (133 MHz) SDRAM memory (running at 100 MHz) The question is, does it configure your SDRAMs correctly? I assume it's on auto config, then the BIOS has to figure out what timings to use for the RAMs by reading their SPD ROM. Problem 1: you run PC133 memory in PC100 configuration. Some PC133 DIMMs contain no configuration data for PC100, so they theoretically couldn't legally be run as PC100. They could be run using the PC133 config - not optimal, but should work. The BIOS has to figure that out, however. This problem is more likely to occur if you're using no-name RAMs instead of branded RAMs by a reputable vendor (you might not even have fully valid config data for PC133 in that case). Problem 2: your BIOS is broken and configures all DIMMs to the configuration values of the first, causing at least one to run with the wrong values, if they have different timing requirements. Given your problem (either DIMM works alone, two don't), this sounds like a more possible candidate. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
O2 Micro CB bridge problems (was: PCMCIA troubles with an Acer TravelMate 513TE)
On Mon, Jun 11, 2001 at 10:08:39AM +0100, Paulo E. Abreu wrote: > Greetings, > > I have this laptop and I am having trouble with pcmcia in every 2.4.x > kernel. > Someone suggested that this could be a BIOS bug ... > Below there is the information, that I think is relevant to this problem. If > more is needed just tell me... You have the exact same problem as I have. Your Cardbus bridge gets memory windows allocated during initialization, but no IO port windows. This seems to be related to the resource allocation code in Linux 2.4. > Now I cannot use any PCMCIA device with this laptop, this is critical as I > cannot have any network connection... Use the drivers from the pcmcia-cs package instead of the kernel code. They don't bother with the abstract interfaces provided by the kernel and do direct pcibios_* function calls. That works where the kernel PCI hotplug code doesn't work for me. Actually I *can* make it work for me, see below for the setpci hack (replace my IO base with a free range on your computer, use the appropriate slot number in the -s argument (that was 13.0 and 13.1 in your case, for each of the PCMCIA slots)). Now back to addressing the hackers who feel addressed (and Martin Mares who I just cc'ed without remorse): I have reported my problems already once some time (a few 2.4 releases at least) back, but it didn't get fixed and pcmcia-cs worked too good so I wasn't very active in this regard. I have a Thinkpad 1200 (more specifically 1161-267), which has the same cardbus bridge Paulo has except for the revision, but see below. The problem is, in short, that the PCI code allocated memory windows for the bridge but no IO windows. The tulip chip on an inserted cb card gets then memory allocated, but the driver complains that it doesn't have IO access and stops. Using modularized drivers I can show that step by step: No drivers loaded, pristine state, no memory or I/O windows: Script started on Wed Jun 13 22:03:14 2001 [root@merv root]# lspci -vvv -s3 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 Cardbus Controller (rev 05) Subsystem: IBM: Unknown device 01a3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 [root@merv root]# cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03bc-03be : parport0 03c0-03df : vesafb 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 7000-70ff : Intel Corporation 82440MX AC'97 Audio Controller 7400-743f : Intel Corporation 82440MX AC'97 Audio Controller 7800-78ff : PCI device 8086:7196 (Intel Corporation) 7c00-7c7f : PCI device 8086:7196 (Intel Corporation) 8000-801f : Intel Corporation 82440MX USB Universal Host Controller 8000-801f : usb-uhci 8040-804f : Intel Corporation 82440MX EIDE Controller 8040-8047 : ide0 Loading the drivers, memory windows get allocated: [root@merv root]# modprobe yenta_socket [root@merv root]# modprobe cb_enabler [root@merv root]# lspci -vvv -s3 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 Cardbus Controller (rev 05) Subsystem: IBM: Unknown device 01a3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 [root@merv root]# dmesg | tail -15 Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 11 for device 00:03.0 PCI: The same IRQ used for device 00:00.1 PCI: The same IRQ used for device 00:00.2 IRQ routing conflict in pirq table for device 00:03.0 Yenta IRQ list 02b8, PCI irq10 Socket status: 3827 cs: cb_alloc(bus 1): vendor 0x1011, device 0x0019 PCI: Failed to allocate resource 0(1000-fff) for 01:00.0 got res[1080:108003ff] for resource 1 of PCI device 1011:0019 got res[1040:1043] for resource 6 of PCI device 1011:0019 PCI: Enabling device 01:00.0 ( -> 0003) Linux Tulip driver version 0.9.15-pre2 (May 16, 2001) tulip: 01:00.0: I/O region (0x0@0x1000) too small, aborting For reference, the cardbus tulip w/o IO ports: [root@merv root]# lspci -vvv -s1: 01:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: Abocom Systems Inc: Unknown device ab01 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 Load driver again, which accepts the IO window base and fixes the limit: [root@merv root]# modprobe yenta_socket [root@merv
O2 Micro CB bridge problems (was: PCMCIA troubles with an Acer TravelMate 513TE)
On Mon, Jun 11, 2001 at 10:08:39AM +0100, Paulo E. Abreu wrote: Greetings, I have this laptop and I am having trouble with pcmcia in every 2.4.x kernel. Someone suggested that this could be a BIOS bug ... Below there is the information, that I think is relevant to this problem. If more is needed just tell me... You have the exact same problem as I have. Your Cardbus bridge gets memory windows allocated during initialization, but no IO port windows. This seems to be related to the resource allocation code in Linux 2.4. Now I cannot use any PCMCIA device with this laptop, this is critical as I cannot have any network connection... Use the drivers from the pcmcia-cs package instead of the kernel code. They don't bother with the abstract interfaces provided by the kernel and do direct pcibios_* function calls. That works where the kernel PCI hotplug code doesn't work for me. Actually I *can* make it work for me, see below for the setpci hack (replace my IO base with a free range on your computer, use the appropriate slot number in the -s argument (that was 13.0 and 13.1 in your case, for each of the PCMCIA slots)). Now back to addressing the hackers who feel addressed (and Martin Mares who I just cc'ed without remorse): I have reported my problems already once some time (a few 2.4 releases at least) back, but it didn't get fixed and pcmcia-cs worked too good so I wasn't very active in this regard. I have a Thinkpad 1200 (more specifically 1161-267), which has the same cardbus bridge Paulo has except for the revision, but see below. The problem is, in short, that the PCI code allocated memory windows for the bridge but no IO windows. The tulip chip on an inserted cb card gets then memory allocated, but the driver complains that it doesn't have IO access and stops. Using modularized drivers I can show that step by step: No drivers loaded, pristine state, no memory or I/O windows: Script started on Wed Jun 13 22:03:14 2001 [root@merv root]# lspci -vvv -s3 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 Cardbus Controller (rev 05) Subsystem: IBM: Unknown device 01a3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Interrupt: pin A routed to IRQ 10 Region 0: Memory at 1000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=04, sec-latency=0 Memory window 0: - Memory window 1: - I/O window 0: -0003 I/O window 1: -0003 BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset- 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 [root@merv root]# cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03bc-03be : parport0 03c0-03df : vesafb 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 7000-70ff : Intel Corporation 82440MX AC'97 Audio Controller 7400-743f : Intel Corporation 82440MX AC'97 Audio Controller 7800-78ff : PCI device 8086:7196 (Intel Corporation) 7c00-7c7f : PCI device 8086:7196 (Intel Corporation) 8000-801f : Intel Corporation 82440MX USB Universal Host Controller 8000-801f : usb-uhci 8040-804f : Intel Corporation 82440MX EIDE Controller 8040-8047 : ide0 Loading the drivers, memory windows get allocated: [root@merv root]# modprobe yenta_socket [root@merv root]# modprobe cb_enabler [root@merv root]# lspci -vvv -s3 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 Cardbus Controller (rev 05) Subsystem: IBM: Unknown device 01a3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- Latency: 168 Interrupt: pin A routed to IRQ 10 Region 0: Memory at 1000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=01, subordinate=01, sec-latency=176 Memory window 0: 1040-107ff000 (prefetchable) Memory window 1: 1080-10bff000 I/O window 0: -0003 I/O window 1: -0003 BridgeCtl: Parity- SERR- ISA- VGA- MAbort- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 [root@merv root]# dmesg | tail -15 Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 11 for device 00:03.0 PCI: The same IRQ used for device 00:00.1 PCI: The same IRQ used for device 00:00.2 IRQ routing conflict in pirq table for device 00:03.0 Yenta IRQ list 02b8, PCI irq10 Socket status: 3827 cs: cb_alloc(bus 1): vendor 0x1011, device 0x0019 PCI: Failed to allocate resource 0(1000-fff) for 01:00.0 got res[1080:108003ff] for
Re: how mmap() works?
On Sun, Apr 01, 2001 at 03:28:05PM -0500, Tim Hockin wrote: > > Without syncing, Linux writes whenever it thinks it's appropriate, e.g. > > when pages have to be freed (I think also when the bdflush writes back > > data, i.e. every 30 seconds by default). > > what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ? They map physically present memory directly and do not have to be synced, since all writes go directly to their destination (which is of course not possible with disk files). I'm not that sure if PCI is a bit special case though, since not all architectures can access it like memory. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how mmap() works?
On Thu, Mar 29, 2001 at 02:14:51PM -0800, Jerry Hong wrote: > Hi, > mmap() creates a mmaped memory associated with a > physical file. If a process updates the mmaped memory, > Linux will updates the file "automatically". If this > is the case, why do we need msync()? For the same reason you might need fsync() or fdatasync(). To force changes to be written now, without having to munmap() the area, so that you have a gurantee that current data is on disk and will not be lost. > If this is not > the case, what is the interval between 2 "WRITE" (IO > request operation) request to the physical file > because it really updates the physical file somehow > even without msync(). Without syncing, Linux writes whenever it thinks it's appropriate, e.g. when pages have to be freed (I think also when the bdflush writes back data, i.e. every 30 seconds by default). -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how mmap() works?
On Thu, Mar 29, 2001 at 02:14:51PM -0800, Jerry Hong wrote: Hi, mmap() creates a mmaped memory associated with a physical file. If a process updates the mmaped memory, Linux will updates the file "automatically". If this is the case, why do we need msync()? For the same reason you might need fsync() or fdatasync(). To force changes to be written now, without having to munmap() the area, so that you have a gurantee that current data is on disk and will not be lost. If this is not the case, what is the interval between 2 "WRITE" (IO request operation) request to the physical file because it really updates the physical file somehow even without msync(). Without syncing, Linux writes whenever it thinks it's appropriate, e.g. when pages have to be freed (I think also when the bdflush writes back data, i.e. every 30 seconds by default). -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how mmap() works?
On Sun, Apr 01, 2001 at 03:28:05PM -0500, Tim Hockin wrote: Without syncing, Linux writes whenever it thinks it's appropriate, e.g. when pages have to be freed (I think also when the bdflush writes back data, i.e. every 30 seconds by default). what about mmap() on non-filesystem files (/dev/mem, /proc/bus/pci...) ? They map physically present memory directly and do not have to be synced, since all writes go directly to their destination (which is of course not possible with disk files). I'm not that sure if PCI is a bit special case though, since not all architectures can access it like memory. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IRQ routing conflict & ressource assignment on Thinkpad
Something that was itching me for a while (and I had a bad conscience for not reporting a bug for so long): I have an IBM Thinkpad i1200 (1161-267, Celeron 550, see lspci below). The PCI code in 2.4 always complains about an IRQ routing conflict wrt the CardBus controller. That used to make it crash when hotplug is configured, since loading the i810 sound module would change the controller's IRQ, then a inserting a card blows it up. Doesn't seem to happen anymore, but the warnings are still there. Another (possibly related) problem is that the controller does not get IO resources assigned, so the Tulip driver won't work. This specifically happens only with kernel hotplug code, pcmcia-cs modules 3.1.22 work for me. The IRQ crashes also happened only with kernel hotplug, the conflict report is always on. Oh, and sometimes the i810 audio driver can hang the system, games seem to trigger that, sound output from e.g. mp3 player don't hurt. But I don't have much data on that yet. Following data is collected from the kernel with PCI hotplug configured in. If someone needs the .config, please ask. This is what dump_pirq says: Interrupt routing table found at address 0xfbdb0: Version 1.0, size 0x0070 Interrupt router is device 00:07.0 PCI exclusive interrupt mask: 0x [] Compatible router: vendor 0x8086 device 0x7198 Device 00:02.0 (slot 0): VGA compatible controller INTA: link 0x60, irq mask 0x0400 [10] Device 00:07.0 (slot 0): ISA bridge INTD: link 0x63, irq mask 0x0400 [10] Device 00:06.0 (slot 0): INTA: link 0x62, irq mask 0x8000 [15] Device 00:03.0 (slot 0): CardBus bridge INTA: link 0x61, irq mask 0x0400 [10] INTB: link 0x62, irq mask 0x0400 [10] Device 00:00.0 (slot 0): Host bridge INTB: link 0x61, irq mask 0x0800 [11] Interrupt router at 00:07.0: Intel 82443MX PCI-to-ISA bridge PIRQ1 (link 0x60): irq 10 PIRQ2 (link 0x61): irq 11 PIRQ3 (link 0x62): unrouted PIRQ4 (link 0x63): irq 10 Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12] Level mask: 0x0c00 [10,11] The relevant lines from dmesg for both problems: Linux version 2.4.2 (root@merv) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Die Feb 27 21:45:50 CET 2001 [...] PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7198] at 00:07.0 got res[1000:1fff] for resource 0 of O2 Micro, Inc. OZ6812 Cardbus Controller [...] Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 11 for device 00:03.0 PCI: The same IRQ used for device 00:00.1 PCI: The same IRQ used for device 00:00.2 IRQ routing conflict in pirq table for device 00:03.0 Intel PCIC probe: not found. [...] Yenta IRQ list 02b8, PCI irq10 Socket status: 3821 [...] PCI: Found IRQ 10 for device 00:07.2 usb-uhci.c: USB UHCI at I/O 0x8000, IRQ 10 usb-uhci.c: Detected 2 ports [...] Removed and reinserted ethernet pccard here: cs: cb_alloc(bus 1): vendor 0x1011, device 0x0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 got res[1080:108003ff] for resource 1 of PCI device 1011:0019 got res[1040:1043] for resource 6 of PCI device 1011:0019 PCI: Enabling device 01:00.0 ( -> 0003) Linux Tulip driver version 0.9.13a (January 20, 2001) tulip: eth0: I/O region (0x0@0x1000) too small, aborting And that's lspci -vvv with the ethernet card inserted: 00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01) Subsystem: IBM: Unknown device 01ab Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IRQ routing conflict ressource assignment on Thinkpad
Something that was itching me for a while (and I had a bad conscience for not reporting a bug for so long): I have an IBM Thinkpad i1200 (1161-267, Celeron 550, see lspci below). The PCI code in 2.4 always complains about an IRQ routing conflict wrt the CardBus controller. That used to make it crash when hotplug is configured, since loading the i810 sound module would change the controller's IRQ, then a inserting a card blows it up. Doesn't seem to happen anymore, but the warnings are still there. Another (possibly related) problem is that the controller does not get IO resources assigned, so the Tulip driver won't work. This specifically happens only with kernel hotplug code, pcmcia-cs modules 3.1.22 work for me. The IRQ crashes also happened only with kernel hotplug, the conflict report is always on. Oh, and sometimes the i810 audio driver can hang the system, games seem to trigger that, sound output from e.g. mp3 player don't hurt. But I don't have much data on that yet. Following data is collected from the kernel with PCI hotplug configured in. If someone needs the .config, please ask. This is what dump_pirq says: Interrupt routing table found at address 0xfbdb0: Version 1.0, size 0x0070 Interrupt router is device 00:07.0 PCI exclusive interrupt mask: 0x [] Compatible router: vendor 0x8086 device 0x7198 Device 00:02.0 (slot 0): VGA compatible controller INTA: link 0x60, irq mask 0x0400 [10] Device 00:07.0 (slot 0): ISA bridge INTD: link 0x63, irq mask 0x0400 [10] Device 00:06.0 (slot 0): INTA: link 0x62, irq mask 0x8000 [15] Device 00:03.0 (slot 0): CardBus bridge INTA: link 0x61, irq mask 0x0400 [10] INTB: link 0x62, irq mask 0x0400 [10] Device 00:00.0 (slot 0): Host bridge INTB: link 0x61, irq mask 0x0800 [11] Interrupt router at 00:07.0: Intel 82443MX PCI-to-ISA bridge PIRQ1 (link 0x60): irq 10 PIRQ2 (link 0x61): irq 11 PIRQ3 (link 0x62): unrouted PIRQ4 (link 0x63): irq 10 Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12] Level mask: 0x0c00 [10,11] The relevant lines from dmesg for both problems: Linux version 2.4.2 (root@merv) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Die Feb 27 21:45:50 CET 2001 [...] PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7198] at 00:07.0 got res[1000:1fff] for resource 0 of O2 Micro, Inc. OZ6812 Cardbus Controller [...] Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 11 for device 00:03.0 PCI: The same IRQ used for device 00:00.1 PCI: The same IRQ used for device 00:00.2 IRQ routing conflict in pirq table for device 00:03.0 Intel PCIC probe: not found. [...] Yenta IRQ list 02b8, PCI irq10 Socket status: 3821 [...] PCI: Found IRQ 10 for device 00:07.2 usb-uhci.c: USB UHCI at I/O 0x8000, IRQ 10 usb-uhci.c: Detected 2 ports [...] Removed and reinserted ethernet pccard here: cs: cb_alloc(bus 1): vendor 0x1011, device 0x0019 PCI: Failed to allocate resource 0 for PCI device 1011:0019 got res[1080:108003ff] for resource 1 of PCI device 1011:0019 got res[1040:1043] for resource 6 of PCI device 1011:0019 PCI: Enabling device 01:00.0 ( - 0003) Linux Tulip driver version 0.9.13a (January 20, 2001) tulip: eth0: I/O region (0x0@0x1000) too small, aborting And that's lspci -vvv with the ethernet card inserted: 00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01) Subsystem: IBM: Unknown device 01ab Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR+ Latency: 32 00:00.1 Multimedia audio controller: Intel Corporation 82440MX AC'97 Audio Controller Subsystem: IBM: Unknown device 01a1 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 11 Region 0: I/O ports at 7000 [size=256] Region 1: I/O ports at 7400 [size=64] 00:00.2 Modem: Intel Corporation: Unknown device 7196 (prog-if 00 [Generic]) Subsystem: IBM: Unknown device 01a2 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 11 Region 0: I/O ports at 7800 [size=256] Region 1: I/O ports at 7c00 [size=128] 00:02.0 VGA compatible controller: Silicon Motion, Inc. SM712 LynxEM+ (rev a0) (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 01a4 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
[PATCH] ieee1394 pcilynx.c SMP fix
Due to a brain malfunction spinlocks were used in pcilynx.c before they
were initialized, causing SMP systems to deadlock. The patch fixes this
and removes one second/redundant initialization of another lock.
diff -ruN linux-2.4.linus/drivers/ieee1394/pcilynx.c
linux-2.4/drivers/ieee1394/pcilynx.c
--- linux-2.4.linus/drivers/ieee1394/pcilynx.c Mon Feb 26 01:39:30 2001
+++ linux-2.4/drivers/ieee1394/pcilynx.cWed Mar 14 01:00:13 2001
@@ -470,8 +470,6 @@
lynx->phy_reg0 = -1;
lynx->async.queue = NULL;
-spin_lock_init(>async.queue_lock);
-spin_lock_init(>phy_reg_lock);
pcl.next = pcl_bus(lynx, lynx->rcv_pcl);
put_pcl(lynx, lynx->rcv_pcl_start, );
@@ -1357,6 +1355,9 @@
lynx->id = num_of_cards-1;
lynx->dev = dev;
+lynx->lock = SPIN_LOCK_UNLOCKED;
+lynx->phy_reg_lock = SPIN_LOCK_UNLOCKED;
+
if (!pci_dma_supported(dev, 0x)) {
FAIL("DMA address limits not supported for PCILynx hardware %d",
lynx->id);
@@ -1456,8 +1457,6 @@
lynx->iso_rcv.pcl_start = alloc_pcl(lynx);
/* all allocations successful - simple init stuff follows */
-
-lynx->lock = SPIN_LOCK_UNLOCKED;
reg_write(lynx, PCI_INT_ENABLE, PCI_INT_DMA_ALL);
--
Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ieee1394 pcilynx.c SMP fix
Due to a brain malfunction spinlocks were used in pcilynx.c before they
were initialized, causing SMP systems to deadlock. The patch fixes this
and removes one second/redundant initialization of another lock.
diff -ruN linux-2.4.linus/drivers/ieee1394/pcilynx.c
linux-2.4/drivers/ieee1394/pcilynx.c
--- linux-2.4.linus/drivers/ieee1394/pcilynx.c Mon Feb 26 01:39:30 2001
+++ linux-2.4/drivers/ieee1394/pcilynx.cWed Mar 14 01:00:13 2001
@@ -470,8 +470,6 @@
lynx-phy_reg0 = -1;
lynx-async.queue = NULL;
-spin_lock_init(lynx-async.queue_lock);
-spin_lock_init(lynx-phy_reg_lock);
pcl.next = pcl_bus(lynx, lynx-rcv_pcl);
put_pcl(lynx, lynx-rcv_pcl_start, pcl);
@@ -1357,6 +1355,9 @@
lynx-id = num_of_cards-1;
lynx-dev = dev;
+lynx-lock = SPIN_LOCK_UNLOCKED;
+lynx-phy_reg_lock = SPIN_LOCK_UNLOCKED;
+
if (!pci_dma_supported(dev, 0x)) {
FAIL("DMA address limits not supported for PCILynx hardware %d",
lynx-id);
@@ -1456,8 +1457,6 @@
lynx-iso_rcv.pcl_start = alloc_pcl(lynx);
/* all allocations successful - simple init stuff follows */
-
-lynx-lock = SPIN_LOCK_UNLOCKED;
reg_write(lynx, PCI_INT_ENABLE, PCI_INT_DMA_ALL);
--
Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hotplug and interrupt context
On Sun, Mar 11, 2001 at 10:18:18PM -0500, Jeff Garzik wrote: > Andreas Bombe wrote: > > > > I couldn't trace that down to be 100% sure and it's better to conform to > > design than implementation, so I'll ask: > > > > Do the probe and remove functions of a pci_driver have to be able to > > work in interrupt context? (i.e. GFP_ATOMIC and stuff) > > No, no interrupt context to worry about. It would really suck if you > couldn't sleep in pci_driver::probe :) Very good. I wasn't sure since I saw GFP_ATOMIC allocations somewhere in the cardbus code which looked like it was in card initialization. But it's also confusing and somewhere was a note saying that some of this is obsolete code which is replaced elsewhere... > For CardBus, it calls schedule_task .. Another thing learned, thanks. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hotplug and interrupt context
On Sun, Mar 11, 2001 at 10:18:18PM -0500, Jeff Garzik wrote: Andreas Bombe wrote: I couldn't trace that down to be 100% sure and it's better to conform to design than implementation, so I'll ask: Do the probe and remove functions of a pci_driver have to be able to work in interrupt context? (i.e. GFP_ATOMIC and stuff) No, no interrupt context to worry about. It would really suck if you couldn't sleep in pci_driver::probe :) Very good. I wasn't sure since I saw GFP_ATOMIC allocations somewhere in the cardbus code which looked like it was in card initialization. But it's also confusing and somewhere was a note saying that some of this is obsolete code which is replaced elsewhere... For CardBus, it calls schedule_task .. Another thing learned, thanks. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hotplug and interrupt context
I couldn't trace that down to be 100% sure and it's better to conform to design than implementation, so I'll ask: Do the probe and remove functions of a pci_driver have to be able to work in interrupt context? (i.e. GFP_ATOMIC and stuff) I expect so, since CardBus handling doesn't start a thread and would call these functions from the context it got the insertion message (interrupt context). -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hotplug and interrupt context
I couldn't trace that down to be 100% sure and it's better to conform to design than implementation, so I'll ask: Do the probe and remove functions of a pci_driver have to be able to work in interrupt context? (i.e. GFP_ATOMIC and stuff) I expect so, since CardBus handling doesn't start a thread and would call these functions from the context it got the insertion message (interrupt context). -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
> Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> > On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> > > Peter Samuelson <[EMAIL PROTECTED]> writes:
> > > > It also sounds like you will be
> > > > breaking the extremely useful C postulate that, at the ABI level at
> > > > least, arrays and pointers are equivalent. I can't see *how* you plan
> > > > to work around that one.
> > >
> > > Huh? Pointers and arrays are clearly different at the ABI level.
> > >
> > > A pointer is a word that contains an address of something.
> > > An array is an array.
> >
> > An array is a word that contains the address of the first element.
>
>
> No. Exercise 3: compile and run this:
> file a.c:
> char array[] = "I'm really an array";
>
> file b.c:
> extern char* array;
>
> main() { printf("array = %s\n", array); }
>
> ... and watch it biting the dust !
Deliberately linking to the wrong symbol is not a point. Might as well
replace file a.c with "int array = 0;". That'll also bite the dust. So?
> in short: an array is NOT a pointer.
In this context we were talking *function calls*, not confusing the
linker. And whether you say "char array[];" or "char *const array;",
array is a pointer. Even more so at the ABI = function call interface.
Another try: Assume that
#include "secret.h"
int main() { printf("array = %s\n", array); return 0; }
is correct code.
Is the variable array a pointer to a char or an array of chars?
Oh well, who cares.
--
Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a crit :
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
Peter Samuelson [EMAIL PROTECTED] writes:
It also sounds like you will be
breaking the extremely useful C postulate that, at the ABI level at
least, arrays and pointers are equivalent. I can't see *how* you plan
to work around that one.
Huh? Pointers and arrays are clearly different at the ABI level.
A pointer is a word that contains an address of something.
An array is an array.
An array is a word that contains the address of the first element.
No. Exercise 3: compile and run this:
file a.c:
char array[] = "I'm really an array";
file b.c:
extern char* array;
main() { printf("array = %s\n", array); }
... and watch it biting the dust !
Deliberately linking to the wrong symbol is not a point. Might as well
replace file a.c with "int array = 0;". That'll also bite the dust. So?
in short: an array is NOT a pointer.
In this context we were talking *function calls*, not confusing the
linker. And whether you say "char array[];" or "char *const array;",
array is a pointer. Even more so at the ABI = function call interface.
Another try: Assume that
#include "secret.h"
int main() { printf("array = %s\n", array); return 0; }
is correct code.
Is the variable array a pointer to a char or an array of chars?
Oh well, who cares.
--
Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote: > Peter Samuelson <[EMAIL PROTECTED]> writes: > > It also sounds like you will be > > breaking the extremely useful C postulate that, at the ABI level at > > least, arrays and pointers are equivalent. I can't see *how* you plan > > to work around that one. > > Huh? Pointers and arrays are clearly different at the ABI level. > > A pointer is a word that contains an address of something. > An array is an array. An array is a word that contains the address of the first element. Exercise 1: What is the difference between the following two declarations at the source level and at the ABI level? a) int main(int argc, char *argv[]) b) int main(int argc, char **argv) Exercise 2: What would the following in hypothetical C startup code do? char *args[10]; int count = 10; ... exit(main(count - 1, args + 1)); -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote: Peter Samuelson [EMAIL PROTECTED] writes: It also sounds like you will be breaking the extremely useful C postulate that, at the ABI level at least, arrays and pointers are equivalent. I can't see *how* you plan to work around that one. Huh? Pointers and arrays are clearly different at the ABI level. A pointer is a word that contains an address of something. An array is an array. An array is a word that contains the address of the first element. Exercise 1: What is the difference between the following two declarations at the source level and at the ABI level? a) int main(int argc, char *argv[]) b) int main(int argc, char **argv) Exercise 2: What would the following in hypothetical C startup code do? char *args[10]; int count = 10; ... exit(main(count - 1, args + 1)); -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [BUGFIX] [RESEND, goddammit!] important fixes for ieee1394 subsystem
I have sent the following patch three times to you during 2.4.1 prepatch
time and you seem to have missed all of them (Jan 15, 19 and 25). I
hope we can manage that for 2.4.2 and get the known bugs with fixes out
of the ieee1394 subsystem. Finally.
Please, either show some sign of life by replying or making a 2.4.2-pre
patch with this included this week. Thanks to the subsystem not being
modified the same patch from 2.4.0 times applies to 2.4.2-pre1.
* It completes the adaption to the new task queue structure. Instead of
plain INIT_LIST_HEAD internal macros are used to make backporting to
2.2 easy (fixes 1 oops, the rest makes initialization just clean).
* PCILynx bus reset handling was modified to make it much more robust
with multiple bus resets in quick succession (fixes possible driver
hangs).
* The definition of ohci_csr_rom was moved from ohci1394.h to
ohci1394.c. The header file is also included in video1394.c (fixes
build failure when neither ohci1394 nor video1394 are configured as
module or not built). There is apparantly a different patch for this
in Alan's tree.
* Five symbols in pcilynx.h were renamed to something more descriptive.
Not a bug fix, but it's so small...
diff -ruN linux-2.4.orig/drivers/ieee1394/guid.c
linux-2.4.linus/drivers/ieee1394/guid.c
--- linux-2.4.orig/drivers/ieee1394/guid.c Mon Jan 1 23:17:36 2001
+++ linux-2.4.linus/drivers/ieee1394/guid.c Mon Feb 5 02:59:17 2001
@@ -163,7 +163,7 @@
return;
}
-INIT_LIST_HEAD(>tq.list);
+INIT_TQ_LINK(greq->tq);
greq->tq.sync = 0;
greq->tq.routine = (void (*)(void*))pkt_complete;
greq->tq.data = greq;
diff -ruN linux-2.4.orig/drivers/ieee1394/hosts.c
linux-2.4.linus/drivers/ieee1394/hosts.c
--- linux-2.4.orig/drivers/ieee1394/hosts.c Mon Jan 1 23:15:56 2001
+++ linux-2.4.linus/drivers/ieee1394/hosts.cMon Feb 5 02:59:17 2001
@@ -106,6 +106,7 @@
sema_init(>tlabel_count, 64);
spin_lock_init(>tlabel_lock);
+INIT_TQ_LINK(h->timeout_tq);
h->timeout_tq.routine = (void (*)(void*))abort_timedouts;
h->timeout_tq.data = h;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_core.c
linux-2.4.linus/drivers/ieee1394/ieee1394_core.c
--- linux-2.4.orig/drivers/ieee1394/ieee1394_core.c Mon Jan 1 23:15:56 2001
+++ linux-2.4.linus/drivers/ieee1394/ieee1394_core.cMon Feb 5 02:59:17 2001
@@ -98,6 +98,7 @@
packet->data_size = data_size;
}
+INIT_TQ_HEAD(packet->complete_tq);
INIT_LIST_HEAD(>list);
sema_init(>state_change, 0);
packet->state = unused;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_types.h
linux-2.4.linus/drivers/ieee1394/ieee1394_types.h
--- linux-2.4.orig/drivers/ieee1394/ieee1394_types.hTue Jan 2 05:53:39 2001
+++ linux-2.4.linus/drivers/ieee1394/ieee1394_types.h Mon Feb 5 02:59:17 2001
@@ -15,6 +15,9 @@
#define V22_COMPAT_MOD_INC_USE_COUNT do {} while (0)
#define V22_COMPAT_MOD_DEC_USE_COUNT do {} while (0)
#define OWNER_THIS_MODULE owner: THIS_MODULE,
+
+#define INIT_TQ_LINK(tq) INIT_LIST_HEAD(&(tq).list)
+#define INIT_TQ_HEAD(tq) INIT_LIST_HEAD(&(tq))
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,18)
diff -ruN linux-2.4.orig/drivers/ieee1394/ohci1394.c
linux-2.4.linus/drivers/ieee1394/ohci1394.c
--- linux-2.4.orig/drivers/ieee1394/ohci1394.c Thu Jan 11 01:34:32 2001
+++ linux-2.4.linus/drivers/ieee1394/ohci1394.c Mon Feb 5 02:59:17 2001
@@ -97,6 +97,81 @@
#include "ieee1394_core.h"
#include "ohci1394.h"
+
+/* This structure is not properly initialized ... it is taken from
+ the lynx_csr_rom written by Andreas ... Some fields in the root
+ directory and the module dependent info needs to be modified
+ I do not have the proper doc */
+quadlet_t ohci_csr_rom[] = {
+/* bus info block */
+0x0404, /* info/CRC length, CRC */
+0x31333934, /* 1394 magic number */
+0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
+0x, /* vendor ID, chip ID high (written from card info) */
+0x, /* chip ID low (written from card info) */
+/* root directory - FIXME */
+0x0009, /* CRC length, CRC */
+0x03080028, /* vendor ID (Texas Instr.) */
+0x8109, /* offset to textual ID */
+0x0c000200, /* node capabilities */
+0x8d0e, /* offset to unique ID */
+0xc710, /* offset to module independent info */
+0x0400, /* module hardware version */
+0x8126, /* offset to textual ID */
+0x0900, /* node hardware version */
+0x8126, /* offset to textual ID */
+/* module vendor ID textual */
+0x0008, /* CRC length, CRC */
+0x,
+0x,
+0x54455841, /* "Texas Instruments" */
+0x5320494e,
+
[PATCH] [BUGFIX] [RESEND, goddammit!] important fixes for ieee1394 subsystem
I have sent the following patch three times to you during 2.4.1 prepatch
time and you seem to have missed all of them (Jan 15, 19 and 25). I
hope we can manage that for 2.4.2 and get the known bugs with fixes out
of the ieee1394 subsystem. Finally.
Please, either show some sign of life by replying or making a 2.4.2-pre
patch with this included this week. Thanks to the subsystem not being
modified the same patch from 2.4.0 times applies to 2.4.2-pre1.
* It completes the adaption to the new task queue structure. Instead of
plain INIT_LIST_HEAD internal macros are used to make backporting to
2.2 easy (fixes 1 oops, the rest makes initialization just clean).
* PCILynx bus reset handling was modified to make it much more robust
with multiple bus resets in quick succession (fixes possible driver
hangs).
* The definition of ohci_csr_rom was moved from ohci1394.h to
ohci1394.c. The header file is also included in video1394.c (fixes
build failure when neither ohci1394 nor video1394 are configured as
module or not built). There is apparantly a different patch for this
in Alan's tree.
* Five symbols in pcilynx.h were renamed to something more descriptive.
Not a bug fix, but it's so small...
diff -ruN linux-2.4.orig/drivers/ieee1394/guid.c
linux-2.4.linus/drivers/ieee1394/guid.c
--- linux-2.4.orig/drivers/ieee1394/guid.c Mon Jan 1 23:17:36 2001
+++ linux-2.4.linus/drivers/ieee1394/guid.c Mon Feb 5 02:59:17 2001
@@ -163,7 +163,7 @@
return;
}
-INIT_LIST_HEAD(greq-tq.list);
+INIT_TQ_LINK(greq-tq);
greq-tq.sync = 0;
greq-tq.routine = (void (*)(void*))pkt_complete;
greq-tq.data = greq;
diff -ruN linux-2.4.orig/drivers/ieee1394/hosts.c
linux-2.4.linus/drivers/ieee1394/hosts.c
--- linux-2.4.orig/drivers/ieee1394/hosts.c Mon Jan 1 23:15:56 2001
+++ linux-2.4.linus/drivers/ieee1394/hosts.cMon Feb 5 02:59:17 2001
@@ -106,6 +106,7 @@
sema_init(h-tlabel_count, 64);
spin_lock_init(h-tlabel_lock);
+INIT_TQ_LINK(h-timeout_tq);
h-timeout_tq.routine = (void (*)(void*))abort_timedouts;
h-timeout_tq.data = h;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_core.c
linux-2.4.linus/drivers/ieee1394/ieee1394_core.c
--- linux-2.4.orig/drivers/ieee1394/ieee1394_core.c Mon Jan 1 23:15:56 2001
+++ linux-2.4.linus/drivers/ieee1394/ieee1394_core.cMon Feb 5 02:59:17 2001
@@ -98,6 +98,7 @@
packet-data_size = data_size;
}
+INIT_TQ_HEAD(packet-complete_tq);
INIT_LIST_HEAD(packet-list);
sema_init(packet-state_change, 0);
packet-state = unused;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_types.h
linux-2.4.linus/drivers/ieee1394/ieee1394_types.h
--- linux-2.4.orig/drivers/ieee1394/ieee1394_types.hTue Jan 2 05:53:39 2001
+++ linux-2.4.linus/drivers/ieee1394/ieee1394_types.h Mon Feb 5 02:59:17 2001
@@ -15,6 +15,9 @@
#define V22_COMPAT_MOD_INC_USE_COUNT do {} while (0)
#define V22_COMPAT_MOD_DEC_USE_COUNT do {} while (0)
#define OWNER_THIS_MODULE owner: THIS_MODULE,
+
+#define INIT_TQ_LINK(tq) INIT_LIST_HEAD((tq).list)
+#define INIT_TQ_HEAD(tq) INIT_LIST_HEAD((tq))
#endif
#if LINUX_VERSION_CODE KERNEL_VERSION(2,3,18)
diff -ruN linux-2.4.orig/drivers/ieee1394/ohci1394.c
linux-2.4.linus/drivers/ieee1394/ohci1394.c
--- linux-2.4.orig/drivers/ieee1394/ohci1394.c Thu Jan 11 01:34:32 2001
+++ linux-2.4.linus/drivers/ieee1394/ohci1394.c Mon Feb 5 02:59:17 2001
@@ -97,6 +97,81 @@
#include "ieee1394_core.h"
#include "ohci1394.h"
+
+/* This structure is not properly initialized ... it is taken from
+ the lynx_csr_rom written by Andreas ... Some fields in the root
+ directory and the module dependent info needs to be modified
+ I do not have the proper doc */
+quadlet_t ohci_csr_rom[] = {
+/* bus info block */
+0x0404, /* info/CRC length, CRC */
+0x31333934, /* 1394 magic number */
+0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
+0x, /* vendor ID, chip ID high (written from card info) */
+0x, /* chip ID low (written from card info) */
+/* root directory - FIXME */
+0x0009, /* CRC length, CRC */
+0x03080028, /* vendor ID (Texas Instr.) */
+0x8109, /* offset to textual ID */
+0x0c000200, /* node capabilities */
+0x8d0e, /* offset to unique ID */
+0xc710, /* offset to module independent info */
+0x0400, /* module hardware version */
+0x8126, /* offset to textual ID */
+0x0900, /* node hardware version */
+0x8126, /* offset to textual ID */
+/* module vendor ID textual */
+0x0008, /* CRC length, CRC */
+0x,
+0x,
+0x54455841, /* "Texas Instruments" */
+0x5320494e,
+
[PATCH] important fixes for ieee1394 subsystem
This patch does the missing conversions for the new task queue code, one
of which fixes an oops (the others are there for cleanliness). I use
some internal macros for easy compatibility to Linux 2.2.
The other change incorporated fixes some issues in the PCILynx driver
with bus resets being initiated before the completion of the first one
and makes it much more robust in this case.
Patch is against 2.4.0. And yes, this really should be in 2.4.1.
diff -ruN linux-2.4.orig/drivers/ieee1394/guid.c linux-2.4/drivers/ieee1394/guid.c
--- linux-2.4.orig/drivers/ieee1394/guid.c Mon Jan 1 23:17:36 2001
+++ linux-2.4/drivers/ieee1394/guid.c Thu Jan 11 02:03:04 2001
@@ -163,7 +163,7 @@
return;
}
-INIT_LIST_HEAD(>tq.list);
+INIT_TQ_LINK(greq->tq);
greq->tq.sync = 0;
greq->tq.routine = (void (*)(void*))pkt_complete;
greq->tq.data = greq;
diff -ruN linux-2.4.orig/drivers/ieee1394/hosts.c linux-2.4/drivers/ieee1394/hosts.c
--- linux-2.4.orig/drivers/ieee1394/hosts.c Mon Jan 1 23:15:56 2001
+++ linux-2.4/drivers/ieee1394/hosts.c Thu Jan 11 01:55:50 2001
@@ -106,6 +106,7 @@
sema_init(>tlabel_count, 64);
spin_lock_init(>tlabel_lock);
+INIT_TQ_LINK(h->timeout_tq);
h->timeout_tq.routine = (void (*)(void*))abort_timedouts;
h->timeout_tq.data = h;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_core.c
linux-2.4/drivers/ieee1394/ieee1394_core.c
--- linux-2.4.orig/drivers/ieee1394/ieee1394_core.c Mon Jan 1 23:15:56 2001
+++ linux-2.4/drivers/ieee1394/ieee1394_core.c Thu Jan 11 01:52:21 2001
@@ -98,6 +98,7 @@
packet->data_size = data_size;
}
+INIT_TQ_HEAD(packet->complete_tq);
INIT_LIST_HEAD(>list);
sema_init(>state_change, 0);
packet->state = unused;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_types.h
linux-2.4/drivers/ieee1394/ieee1394_types.h
--- linux-2.4.orig/drivers/ieee1394/ieee1394_types.hTue Jan 2 05:53:39 2001
+++ linux-2.4/drivers/ieee1394/ieee1394_types.h Thu Jan 11 02:25:53 2001
@@ -15,6 +15,9 @@
#define V22_COMPAT_MOD_INC_USE_COUNT do {} while (0)
#define V22_COMPAT_MOD_DEC_USE_COUNT do {} while (0)
#define OWNER_THIS_MODULE owner: THIS_MODULE,
+
+#define INIT_TQ_LINK(tq) INIT_LIST_HEAD(&(tq).list)
+#define INIT_TQ_HEAD(tq) INIT_LIST_HEAD(&(tq))
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,18)
diff -ruN linux-2.4.orig/drivers/ieee1394/ohci1394.c
linux-2.4/drivers/ieee1394/ohci1394.c
--- linux-2.4.orig/drivers/ieee1394/ohci1394.c Thu Jan 11 01:34:32 2001
+++ linux-2.4/drivers/ieee1394/ohci1394.c Thu Jan 11 02:04:48 2001
@@ -1641,7 +1641,7 @@
/* initialize bottom handler */
d->task.sync = 0;
-INIT_LIST_HEAD(>task.list);
+INIT_TQ_LINK(d->task);
d->task.routine = dma_rcv_bh;
d->task.data = (void*)d;
@@ -1730,6 +1730,7 @@
spin_lock_init(>lock);
/* initialize bottom handler */
+INIT_TQ_LINK(d->task);
d->task.routine = dma_trm_bh;
d->task.data = (void*)d;
diff -ruN linux-2.4.orig/drivers/ieee1394/pcilynx.c
linux-2.4/drivers/ieee1394/pcilynx.c
--- linux-2.4.orig/drivers/ieee1394/pcilynx.c Mon Jan 1 23:17:36 2001
+++ linux-2.4/drivers/ieee1394/pcilynx.cThu Jan 11 02:00:27 2001
@@ -289,7 +289,8 @@
char phyreg[7];
int i;
-for (i = 0; i < 7; i++) {
+phyreg[0] = lynx->phy_reg0;
+for (i = 1; i < 7; i++) {
phyreg[i] = get_phy_reg(lynx, i);
}
@@ -317,13 +318,18 @@
return lsid;
}
-static void handle_selfid(struct ti_lynx *lynx, struct hpsb_host *host, size_t size)
+static void handle_selfid(struct ti_lynx *lynx, struct hpsb_host *host)
{
quadlet_t *q = lynx->rcv_page;
-int phyid, isroot;
+int phyid, isroot, size;
quadlet_t lsid = 0;
int i;
+if (lynx->phy_reg0 == -1 || lynx->selfid_size == -1) return;
+
+size = lynx->selfid_size;
+phyid = lynx->phy_reg0;
+
i = (size > 16 ? 16 : size) / 4 - 1;
while (i >= 0) {
cpu_to_be32s([i]);
@@ -334,7 +340,6 @@
lsid = generate_own_selfid(lynx, host);
}
-phyid = get_phy_reg(lynx, 0);
isroot = (phyid & 2) != 0;
phyid >>= 2;
PRINT(KERN_INFO, lynx->id, "SelfID process finished (phyid %d, %s)",
@@ -369,9 +374,14 @@
hpsb_selfid_received(host, lsid);
}
-if (isroot) reg_set_bits(lynx, LINK_CONTROL, LINK_CONTROL_CYCMASTER);
-
hpsb_selfid_complete(host, phyid, isroot);
+
+if (host->in_bus_reset) return;
+
+if (isroot) reg_set_bits(lynx, LINK_CONTROL, LINK_CONTROL_CYCMASTER);
+reg_set_bits(lynx, LINK_CONTROL,
+ LINK_CONTROL_RCV_CMP_VALID |
[PATCH] important fixes for ieee1394 subsystem
This patch does the missing conversions for the new task queue code, one
of which fixes an oops (the others are there for cleanliness). I use
some internal macros for easy compatibility to Linux 2.2.
The other change incorporated fixes some issues in the PCILynx driver
with bus resets being initiated before the completion of the first one
and makes it much more robust in this case.
Patch is against 2.4.0. And yes, this really should be in 2.4.1.
diff -ruN linux-2.4.orig/drivers/ieee1394/guid.c linux-2.4/drivers/ieee1394/guid.c
--- linux-2.4.orig/drivers/ieee1394/guid.c Mon Jan 1 23:17:36 2001
+++ linux-2.4/drivers/ieee1394/guid.c Thu Jan 11 02:03:04 2001
@@ -163,7 +163,7 @@
return;
}
-INIT_LIST_HEAD(greq-tq.list);
+INIT_TQ_LINK(greq-tq);
greq-tq.sync = 0;
greq-tq.routine = (void (*)(void*))pkt_complete;
greq-tq.data = greq;
diff -ruN linux-2.4.orig/drivers/ieee1394/hosts.c linux-2.4/drivers/ieee1394/hosts.c
--- linux-2.4.orig/drivers/ieee1394/hosts.c Mon Jan 1 23:15:56 2001
+++ linux-2.4/drivers/ieee1394/hosts.c Thu Jan 11 01:55:50 2001
@@ -106,6 +106,7 @@
sema_init(h-tlabel_count, 64);
spin_lock_init(h-tlabel_lock);
+INIT_TQ_LINK(h-timeout_tq);
h-timeout_tq.routine = (void (*)(void*))abort_timedouts;
h-timeout_tq.data = h;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_core.c
linux-2.4/drivers/ieee1394/ieee1394_core.c
--- linux-2.4.orig/drivers/ieee1394/ieee1394_core.c Mon Jan 1 23:15:56 2001
+++ linux-2.4/drivers/ieee1394/ieee1394_core.c Thu Jan 11 01:52:21 2001
@@ -98,6 +98,7 @@
packet-data_size = data_size;
}
+INIT_TQ_HEAD(packet-complete_tq);
INIT_LIST_HEAD(packet-list);
sema_init(packet-state_change, 0);
packet-state = unused;
diff -ruN linux-2.4.orig/drivers/ieee1394/ieee1394_types.h
linux-2.4/drivers/ieee1394/ieee1394_types.h
--- linux-2.4.orig/drivers/ieee1394/ieee1394_types.hTue Jan 2 05:53:39 2001
+++ linux-2.4/drivers/ieee1394/ieee1394_types.h Thu Jan 11 02:25:53 2001
@@ -15,6 +15,9 @@
#define V22_COMPAT_MOD_INC_USE_COUNT do {} while (0)
#define V22_COMPAT_MOD_DEC_USE_COUNT do {} while (0)
#define OWNER_THIS_MODULE owner: THIS_MODULE,
+
+#define INIT_TQ_LINK(tq) INIT_LIST_HEAD((tq).list)
+#define INIT_TQ_HEAD(tq) INIT_LIST_HEAD((tq))
#endif
#if LINUX_VERSION_CODE KERNEL_VERSION(2,3,18)
diff -ruN linux-2.4.orig/drivers/ieee1394/ohci1394.c
linux-2.4/drivers/ieee1394/ohci1394.c
--- linux-2.4.orig/drivers/ieee1394/ohci1394.c Thu Jan 11 01:34:32 2001
+++ linux-2.4/drivers/ieee1394/ohci1394.c Thu Jan 11 02:04:48 2001
@@ -1641,7 +1641,7 @@
/* initialize bottom handler */
d-task.sync = 0;
-INIT_LIST_HEAD(d-task.list);
+INIT_TQ_LINK(d-task);
d-task.routine = dma_rcv_bh;
d-task.data = (void*)d;
@@ -1730,6 +1730,7 @@
spin_lock_init(d-lock);
/* initialize bottom handler */
+INIT_TQ_LINK(d-task);
d-task.routine = dma_trm_bh;
d-task.data = (void*)d;
diff -ruN linux-2.4.orig/drivers/ieee1394/pcilynx.c
linux-2.4/drivers/ieee1394/pcilynx.c
--- linux-2.4.orig/drivers/ieee1394/pcilynx.c Mon Jan 1 23:17:36 2001
+++ linux-2.4/drivers/ieee1394/pcilynx.cThu Jan 11 02:00:27 2001
@@ -289,7 +289,8 @@
char phyreg[7];
int i;
-for (i = 0; i 7; i++) {
+phyreg[0] = lynx-phy_reg0;
+for (i = 1; i 7; i++) {
phyreg[i] = get_phy_reg(lynx, i);
}
@@ -317,13 +318,18 @@
return lsid;
}
-static void handle_selfid(struct ti_lynx *lynx, struct hpsb_host *host, size_t size)
+static void handle_selfid(struct ti_lynx *lynx, struct hpsb_host *host)
{
quadlet_t *q = lynx-rcv_page;
-int phyid, isroot;
+int phyid, isroot, size;
quadlet_t lsid = 0;
int i;
+if (lynx-phy_reg0 == -1 || lynx-selfid_size == -1) return;
+
+size = lynx-selfid_size;
+phyid = lynx-phy_reg0;
+
i = (size 16 ? 16 : size) / 4 - 1;
while (i = 0) {
cpu_to_be32s(q[i]);
@@ -334,7 +340,6 @@
lsid = generate_own_selfid(lynx, host);
}
-phyid = get_phy_reg(lynx, 0);
isroot = (phyid 2) != 0;
phyid = 2;
PRINT(KERN_INFO, lynx-id, "SelfID process finished (phyid %d, %s)",
@@ -369,9 +374,14 @@
hpsb_selfid_received(host, lsid);
}
-if (isroot) reg_set_bits(lynx, LINK_CONTROL, LINK_CONTROL_CYCMASTER);
-
hpsb_selfid_complete(host, phyid, isroot);
+
+if (host-in_bus_reset) return;
+
+if (isroot) reg_set_bits(lynx, LINK_CONTROL, LINK_CONTROL_CYCMASTER);
+reg_set_bits(lynx, LINK_CONTROL,
+ LINK_CONTROL_RCV_CMP_VALID | LINK_CONTROL_TX_ASYNC_EN
+
Re: 2.4.0: ieee1394: got invalid ack 3 from node 65473 (tcode 4)
On Wed, Jan 10, 2001 at 04:48:42AM +0100, Wolfgang Spraul wrote: > Incompatibility with "Sarotech FHD-352F/U Rev 1.0" > > Using an external IDE drive in the Sarotech FireWire enclosure fails, even > though the Sarotech unit works with Win2K and other SBP2 drives work for me > (with Linux). > > I'm using 2.4.0 together with sbp2_1394_122300.tar.gz. > ACK code 3 is not even mentioned in ieee1394.h. That's because it's defined as reserved in the standard and therefore it says "invalid ack". The interesting would be whether we really get that code or if there is a bug in the driver somewhere. > I understand that the SBP2 driver is not (yet) included, but it will be shortly. > Also, I guess the same problem applies to raw1394.o together with the Sarotech > enclosure. Could you test that with testlibraw? (This program is built with libraw and not installed currently.) -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0: ieee1394: got invalid ack 3 from node 65473 (tcode 4)
On Wed, Jan 10, 2001 at 04:48:42AM +0100, Wolfgang Spraul wrote: Incompatibility with "Sarotech FHD-352F/U Rev 1.0" Using an external IDE drive in the Sarotech FireWire enclosure fails, even though the Sarotech unit works with Win2K and other SBP2 drives work for me (with Linux). I'm using 2.4.0 together with sbp2_1394_122300.tar.gz. ACK code 3 is not even mentioned in ieee1394.h. That's because it's defined as reserved in the standard and therefore it says "invalid ack". The interesting would be whether we really get that code or if there is a bug in the driver somewhere. I understand that the SBP2 driver is not (yet) included, but it will be shortly. Also, I guess the same problem applies to raw1394.o together with the Sarotech enclosure. Could you test that with testlibraw? (This program is built with libraw and not installed currently.) -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: prerelease total nonmodular compile, compiler warnings, linking errors
On Tue, Jan 02, 2001 at 03:56:54PM +0200, Elmer Joandi wrote: > > compiling everything builtin, (exept RCPCI, which does not compile) > > linking errors: > drivers/ieee1394/ieee1394.a is not made, quick hack to use .o to see other > errors. You're then using the ieee1394.o module object which doesn't include the hardware and highlevel drivers. I've sent a patch to Linus already and cc'd the mailing list also. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fixed Makefile fix for ieee1394
On Tue, Jan 02, 2001 at 06:43:57AM +0100, Andreas Bombe wrote: > Now that I've had the time to understand the new kernel makefile > structure the patch Kai Germaschewski posted is indeed the correct fix > (move include line up). Furthermore it builds an .o object in the > static compiled case now. I don't see any reason to choose the .a > format and most other drivers also do .o. The first patch had spaces where a tab should be and so failed to apply cleanly. This one with the trivial fix should work better (the O_TARGET is now also defined with ':=' ). diff -ruN linux-2.4.orig/Makefile linux-2.4.linus/Makefile --- linux-2.4.orig/Makefile Tue Jan 2 03:38:50 2001 +++ linux-2.4.linus/MakefileTue Jan 2 05:12:36 2001 @@ -145,7 +145,7 @@ DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o -DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a +DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),) DRIVERS-y += drivers/cdrom/driver.o diff -ruN linux-2.4.orig/drivers/ieee1394/Makefile linux-2.4.linus/drivers/ieee1394/Makefile --- linux-2.4.orig/drivers/ieee1394/MakefileTue Jan 2 03:38:59 2001 +++ linux-2.4.linus/drivers/ieee1394/Makefile Tue Jan 2 05:12:38 2001 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile. # -L_TARGET := ieee1394.a +O_TARGET := ieee1394drv.o export-objs := ieee1394_syms.o @@ -23,7 +23,7 @@ obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o +include $(TOPDIR)/Rules.make + ieee1394.o: $(ieee1394-objs) $(LD) -r -o $@ $(ieee1394-objs) - -include $(TOPDIR)/Rules.make -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: prerelease total nonmodular compile, compiler warnings, linking errors
On Tue, Jan 02, 2001 at 03:56:54PM +0200, Elmer Joandi wrote: compiling everything builtin, (exept RCPCI, which does not compile) linking errors: drivers/ieee1394/ieee1394.a is not made, quick hack to use .o to see other errors. You're then using the ieee1394.o module object which doesn't include the hardware and highlevel drivers. I've sent a patch to Linus already and cc'd the mailing list also. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OOPS] kacpid dies on boot 2.4.0-prerelease
Attached is a ksymoops processed oops which kacpid creates as part of its initialization (i.e. at boot time). It was connected to AC power with a full battery, if that is significant. Kernel is 2.4.0-prerelease. The machine is a IBM Thinkpad i1200 series (to be more specific model 1161-267), Coppermine Celeron CPU 550MHz, 64MB RAM, BIOS updated to 1.0R. This machine works fine under APM except that it sucks as much power on suspend than when running (LCD and HD shut off, that's all). With ACPI I have the contrary problem that it goes into CPU powersave even when it should be running normally. The userspace bogomips program normally reports 546bm but only 64bm when running ACPI (and it is slow; kernel cpuinfo reports 1040bm in both cases, it is reduced in speed only after kernel did its own measurement). This could be related to the kacipd failure however. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ ksymoops 2.3.4 on i686 2.4.0-prerelease-acpi. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-prerelease-acpi/ (default) -m /boot/System.map-2.4.0-prerelease-acpi (specified) Unable to handle kernel NULL pointer dereference at virtual address c01ac476 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: a800 ebx: c3fa1ea4 ecx: 001e edx: c1123770 esi: edi: c027e3fc ebp: c027e378 esp: c3fa1e84 ds: 0018 es: 0018 ss: 0018 Process kacpid (pid: 7, stackpage=c3fa1000) Stack: c3f86360 c3fa1f1c c3fa1f78 c3f86360 c3f86360 c3fa1f1c c3fa1f78 c1123770 00f0 c1123760 c01ac597 c3f86360 c027e378 c020ef80 c3f86360 c3fa1f1c c3fa1f78 0006 30544142 0009 30504e50 00413043 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: ac aa 84 c0 75 f7 f3 aa 8b 43 04 50 e8 4d ab f7 ff 31 c0 83 >>EIP; c01ac476<= Trace; c01ac597 Trace; c020ef80 <_acpi_ctype+3700/6a45> Trace; c01988e1 Trace; c01a6187 Trace; c01a5a13 Trace; c020ea58 <_acpi_ctype+31d8/6a45> Trace; c01a61d7 Trace; c01a60e0 Trace; c01ac494 Trace; c020f30e <_acpi_ctype+3a8e/6a45> Trace; c01ac96c Trace; c020f30e <_acpi_ctype+3a8e/6a45> Trace; c01ac494 Trace; c020ea58 <_acpi_ctype+31d8/6a45> Trace; c020fc22 <_acpi_ctype+43a2/6a45> Trace; c01adaf8 Trace; c020fc1c <_acpi_ctype+439c/6a45> Trace; c01adb12 Trace; c01ac12f Trace; c020eb82 <_acpi_ctype+3302/6a45> Trace; c0220018 <__ksymtab_arp_broken_ops+0/8> Trace; c01074c3 Trace; c01074cc Code; c01ac476 <_EIP>: Code; c01ac476<= 0: aclods %ds:(%esi),%al <= Code; c01ac477 1: aastos %al,%es:(%edi) Code; c01ac478 2: 84 c0 test %al,%al Code; c01ac47a 4: 75 f7 jnefffd <_EIP+0xfffd> c01ac473 Code; c01ac47c 6: f3 aa repz stos %al,%es:(%edi) Code; c01ac47e 8: 8b 43 04 mov0x4(%ebx),%eax Code; c01ac481 b: 50push %eax Code; c01ac482 c: e8 4d ab f7 ffcall fff7ab5e <_EIP+0xfff7ab5e> c0126fd4 Code; c01ac487 11: 31 c0 xor%eax,%eax Code; c01ac489 13: 83 00 00 addl $0x0,(%eax)
[PATCH] Makefile fix for ieee1394
Now that I've had the time to understand the new kernel makefile structure the patch Kai Germaschewski posted is indeed the correct fix (move include line up). Furthermore it builds an .o object in the static compiled case now. I don't see any reason to choose the .a format and most other drivers also do .o. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ diff -ruN linux-2.4.orig/Makefile linux-2.4/Makefile --- linux-2.4.orig/Makefile Tue Jan 2 03:38:50 2001 +++ linux-2.4/Makefile Tue Jan 2 05:12:36 2001 @@ -145,7 +145,7 @@ DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o -DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a +DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),) DRIVERS-y += drivers/cdrom/driver.o diff -ruN linux-2.4.orig/drivers/ieee1394/Makefile linux-2.4/drivers/ieee1394/Makefile --- linux-2.4.orig/drivers/ieee1394/MakefileTue Jan 2 03:38:59 2001 +++ linux-2.4/drivers/ieee1394/Makefile Tue Jan 2 05:12:38 2001 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile. # -L_TARGET := ieee1394.a +O_TARGET = ieee1394drv.o export-objs := ieee1394_syms.o @@ -23,7 +23,7 @@ obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o +include $(TOPDIR)/Rules.make + ieee1394.o: $(ieee1394-objs) $(LD) -r -o $@ $(ieee1394-objs) - -include $(TOPDIR)/Rules.make - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OOPS] kacpid dies on boot 2.4.0-prerelease
Attached is a ksymoops processed oops which kacpid creates as part of its initialization (i.e. at boot time). It was connected to AC power with a full battery, if that is significant. Kernel is 2.4.0-prerelease. The machine is a IBM Thinkpad i1200 series (to be more specific model 1161-267), Coppermine Celeron CPU 550MHz, 64MB RAM, BIOS updated to 1.0R. This machine works fine under APM except that it sucks as much power on suspend than when running (LCD and HD shut off, that's all). With ACPI I have the contrary problem that it goes into CPU powersave even when it should be running normally. The userspace bogomips program normally reports 546bm but only 64bm when running ACPI (and it is slow; kernel cpuinfo reports 1040bm in both cases, it is reduced in speed only after kernel did its own measurement). This could be related to the kacipd failure however. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ ksymoops 2.3.4 on i686 2.4.0-prerelease-acpi. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-prerelease-acpi/ (default) -m /boot/System.map-2.4.0-prerelease-acpi (specified) Unable to handle kernel NULL pointer dereference at virtual address c01ac476 *pde = Oops: CPU:0 EIP:0010:[c01ac476] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: a800 ebx: c3fa1ea4 ecx: 001e edx: c1123770 esi: edi: c027e3fc ebp: c027e378 esp: c3fa1e84 ds: 0018 es: 0018 ss: 0018 Process kacpid (pid: 7, stackpage=c3fa1000) Stack: c3f86360 c3fa1f1c c3fa1f78 c3f86360 c3f86360 c3fa1f1c c3fa1f78 c1123770 00f0 c1123760 c01ac597 c3f86360 c027e378 c020ef80 c3f86360 c3fa1f1c c3fa1f78 0006 30544142 0009 30504e50 00413043 Call Trace: [c01ac597] [c020ef80] [c01988e1] [c01a6187] [c01a5a13] [c020ea58] [c01a61d7] [c01a60e0] [c01ac494] [c020f30e] [c01ac96c] [c020f30e] [c01ac494] [c020ea58] [c020fc22] [c01adaf8] [c020fc1c] [c01adb12] [c01ac12f] [c020eb82] [c0220018] [c01074c3] [c01074cc] Code: ac aa 84 c0 75 f7 f3 aa 8b 43 04 50 e8 4d ab f7 ff 31 c0 83 EIP; c01ac476 acpi_get_battery_info+14e/16c = Trace; c01ac597 acpi_found_cmbatt+103/16c Trace; c020ef80 _acpi_ctype+3700/6a45 Trace; c01988e1 acpi_cm_execute_HID+75/80 Trace; c01a6187 acpi_ns_get_device_callback+a7/b4 Trace; c01a5a13 acpi_ns_walk_namespace+87/104 Trace; c020ea58 _acpi_ctype+31d8/6a45 Trace; c01a61d7 acpi_get_devices+43/6c Trace; c01a60e0 acpi_ns_get_device_callback+0/b4 Trace; c01ac494 acpi_found_cmbatt+0/16c Trace; c020f30e _acpi_ctype+3a8e/6a45 Trace; c01ac96c acpi_cmbatt_init+18/94 Trace; c020f30e _acpi_ctype+3a8e/6a45 Trace; c01ac494 acpi_found_cmbatt+0/16c Trace; c020ea58 _acpi_ctype+31d8/6a45 Trace; c020fc22 _acpi_ctype+43a2/6a45 Trace; c01adaf8 acpi_power_init+40/60 Trace; c020fc1c _acpi_ctype+439c/6a45 Trace; c01adb12 acpi_power_init+5a/60 Trace; c01ac12f acpi_thread+eb/21c Trace; c020eb82 _acpi_ctype+3302/6a45 Trace; c0220018 __ksymtab_arp_broken_ops+0/8 Trace; c01074c3 kernel_thread+1f/38 Trace; c01074cc kernel_thread+28/38 Code; c01ac476 acpi_get_battery_info+14e/16c _EIP: Code; c01ac476 acpi_get_battery_info+14e/16c = 0: aclods %ds:(%esi),%al = Code; c01ac477 acpi_get_battery_info+14f/16c 1: aastos %al,%es:(%edi) Code; c01ac478 acpi_get_battery_info+150/16c 2: 84 c0 test %al,%al Code; c01ac47a acpi_get_battery_info+152/16c 4: 75 f7 jnefffd _EIP+0xfffd c01ac473 acpi_get_battery_info+14b/16c Code; c01ac47c acpi_get_battery_info+154/16c 6: f3 aa repz stos %al,%es:(%edi) Code; c01ac47e acpi_get_battery_info+156/16c 8: 8b 43 04 mov0x4(%ebx),%eax Code; c01ac481 acpi_get_battery_info+159/16c b: 50push %eax Code; c01ac482 acpi_get_battery_info+15a/16c c: e8 4d ab f7 ffcall fff7ab5e _EIP+0xfff7ab5e c0126fd4 kfree+0/b0 Code; c01ac487 acpi_get_battery_info+15f/16c 11: 31 c0 xor%eax,%eax Code; c01ac489 acpi_get_battery_info+161/16c 13: 83 00 00 addl $0x0,(%eax)
[PATCH] Makefile fix for ieee1394
Now that I've had the time to understand the new kernel makefile structure the patch Kai Germaschewski posted is indeed the correct fix (move include line up). Furthermore it builds an .o object in the static compiled case now. I don't see any reason to choose the .a format and most other drivers also do .o. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ diff -ruN linux-2.4.orig/Makefile linux-2.4/Makefile --- linux-2.4.orig/Makefile Tue Jan 2 03:38:50 2001 +++ linux-2.4/Makefile Tue Jan 2 05:12:36 2001 @@ -145,7 +145,7 @@ DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o -DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a +DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),) DRIVERS-y += drivers/cdrom/driver.o diff -ruN linux-2.4.orig/drivers/ieee1394/Makefile linux-2.4/drivers/ieee1394/Makefile --- linux-2.4.orig/drivers/ieee1394/MakefileTue Jan 2 03:38:59 2001 +++ linux-2.4/drivers/ieee1394/Makefile Tue Jan 2 05:12:38 2001 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile. # -L_TARGET := ieee1394.a +O_TARGET = ieee1394drv.o export-objs := ieee1394_syms.o @@ -23,7 +23,7 @@ obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o +include $(TOPDIR)/Rules.make + ieee1394.o: $(ieee1394-objs) $(LD) -r -o $@ $(ieee1394-objs) - -include $(TOPDIR)/Rules.make - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12: PCMCIA IRQ assignments?
On Tue, Dec 26, 2000 at 07:24:39AM -0500, [EMAIL PROTECTED] wrote: > > Hello, > > I have a Sager NP9820 laptop with an ALI chipset and a TI PCI1251BGFN > PCMCIA chipset. For some reason, when I use the yenta module under 2.4.0, > it gets an incorrect IRQ assignment. It uses IRQ11, which is also used by > my ATI Rage Pro card... therefore, when you install this module, the > machine locks up. > > If I use the pcmcia card services under 2.2.16, then the PCMCIA bridge > gets a correct assignment of IRQ 10. I've poked around a bit and haven't > found a way to force the 2.4.0 module to use a specific IRQ... is there a > way to do this without hardcoding it? Do you have a sound driver loaded? I can use my CardBus Ethernet card only without a sound driver, then the CardBus bridge and Ethernet card show up on IRQ10. Mysteriously however loading the i810_audio driver (for a 440MX chip) moves the bridge to IRQ11 (the same as the 440MX). No lockup, but the bridge and Ethernet card don't work then. I'd be interested what happens in your case. More specifically, as the PCI code enables the 440MX sound device it logs that it uses the same IRQ as the cb bridge, meaning the IRQ changed already. This is 2.4.0-test12. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12: PCMCIA IRQ assignments?
On Tue, Dec 26, 2000 at 07:24:39AM -0500, [EMAIL PROTECTED] wrote: Hello, I have a Sager NP9820 laptop with an ALI chipset and a TI PCI1251BGFN PCMCIA chipset. For some reason, when I use the yenta module under 2.4.0, it gets an incorrect IRQ assignment. It uses IRQ11, which is also used by my ATI Rage Pro card... therefore, when you install this module, the machine locks up. If I use the pcmcia card services under 2.2.16, then the PCMCIA bridge gets a correct assignment of IRQ 10. I've poked around a bit and haven't found a way to force the 2.4.0 module to use a specific IRQ... is there a way to do this without hardcoding it? Do you have a sound driver loaded? I can use my CardBus Ethernet card only without a sound driver, then the CardBus bridge and Ethernet card show up on IRQ10. Mysteriously however loading the i810_audio driver (for a 440MX chip) moves the bridge to IRQ11 (the same as the 440MX). No lockup, but the bridge and Ethernet card don't work then. I'd be interested what happens in your case. More specifically, as the PCI code enables the 440MX sound device it logs that it uses the same IRQ as the cb bridge, meaning the IRQ changed already. This is 2.4.0-test12. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: how to capture long oops w/o having second machine
On Tue, Dec 12, 2000 at 09:34:30AM -0500, Mohammad A. Haque wrote: > Someone gave me a really awesome idea about possibly using a palm pilot > to capture the oops. Anyone know if it will be a problem using > /dev/ttyUSB0 as the serial port? The driver itself has to provide support for serial console. If the USB serial driver doesn't (I don't know) it won't work. Check the config options for USB serial, if it doesn't offer an option for console on USB serial port then you're out of luck. Unless the USB serial driver in some strange way hooks into the standard serial driver, but then someone more knowledgeable should answer that question. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: how to capture long oops w/o having second machine
On Tue, Dec 12, 2000 at 09:34:30AM -0500, Mohammad A. Haque wrote: Someone gave me a really awesome idea about possibly using a palm pilot to capture the oops. Anyone know if it will be a problem using /dev/ttyUSB0 as the serial port? The driver itself has to provide support for serial console. If the USB serial driver doesn't (I don't know) it won't work. Check the config options for USB serial, if it doesn't offer an option for console on USB serial port then you're out of luck. Unless the USB serial driver in some strange way hooks into the standard serial driver, but then someone more knowledgeable should answer that question. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre3 (FireWire issue)
On Thu, Nov 30, 2000 at 11:00:07PM -0700, Dax Kelson wrote: > Linus Torvalds said once upon a time (Tue, 28 Nov 2000): > > > - pre3: > > - Andreas Bombe: ieee1394 cleanups and fixes > > Linus, Andreas, > > I've been using this same config since FireWire was merged, just tried out > test12-pre3 and got an unresolved symbol problem with raw1394.o Frankly, I don't know where the missing symbols could come from. Nothing in that area was recently changed. The patch merged into pre3 was just removing Linux 2.2 compatibility macros and fixing two bugs, symbols were not messed with. I haven't compiled pre3 myself so far, however. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre3 (FireWire issue)
On Thu, Nov 30, 2000 at 11:00:07PM -0700, Dax Kelson wrote: Linus Torvalds said once upon a time (Tue, 28 Nov 2000): - pre3: - Andreas Bombe: ieee1394 cleanups and fixes Linus, Andreas, I've been using this same config since FireWire was merged, just tried out test12-pre3 and got an unresolved symbol problem with raw1394.o Frankly, I don't know where the missing symbols could come from. Nothing in that area was recently changed. The patch merged into pre3 was just removing Linux 2.2 compatibility macros and fixing two bugs, symbols were not messed with. I haven't compiled pre3 myself so far, however. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
On Thu, Nov 23, 2000 at 10:04:18PM +0100, Bjorn Wesen wrote:
> On Thu, 23 Nov 2000, Andreas Bombe wrote:
> > > I may be wrong on this, but I thought that copy_{to,from}_user are
> > > only necessary if the address range you are accessing might cause a
> > > fault which Linux cannot handle (ie. one which would cause the
> > > application to segfault if it accessed that memory). If it is only a
> >
> > It is wrong. copy_*_user handle the page faults, whether they are good
> > faults (swapped out, copy on write) or bad faults (illegal access).
> > Without these macros you get the "unable to handle kernel page fault"
> > oops message if a fault occurs.
>
> Yes but only if it's a real fault, not if the address range actually is
> a valid VMA which needs paging, COW'ing or related OS ops. copy_*_user
> does not do the access in any different way than a "manual" access or
> memcpy does, it just adds a .fixup section that tells the do_page_fault
> handler that it should not segfault the kernel itself if the copy takes a
> big fault at any point, instead it should jump to the fixup which makes
> the copy routine return an error message.
You're right, I remembered wrong.
> > > (1) In a "top half" thread, can I now access this memory without the
> > > access macros (since I know the address range is valid)?
> >
> > The address is valid, the pages probably aren't. In fact, extending the
> > address space only creates read-only mappings to the global zeroed page
> > if I remember right.
>
> But it does not matter that the pages aren't there physically, any kind of
> access (including an access from kernel-mode) will bring about the same
> COW/change-on-write mechanism as copy_to_user or a user-mode access would.
However these faults can let you sleep (swap-in, or swap-out to make
room for a COW page). That's defined for the uaccess macros, but might
come very unexpected with a memcpy. Unexpected sleeps alone can make a
crash if the surrounding code does not allow it.
It's a moot point anyway, memcpy with user space is illegal.
--
Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
On Thu, Nov 23, 2000 at 10:04:18PM +0100, Bjorn Wesen wrote:
On Thu, 23 Nov 2000, Andreas Bombe wrote:
I may be wrong on this, but I thought that copy_{to,from}_user are
only necessary if the address range you are accessing might cause a
fault which Linux cannot handle (ie. one which would cause the
application to segfault if it accessed that memory). If it is only a
It is wrong. copy_*_user handle the page faults, whether they are good
faults (swapped out, copy on write) or bad faults (illegal access).
Without these macros you get the "unable to handle kernel page fault"
oops message if a fault occurs.
Yes but only if it's a real fault, not if the address range actually is
a valid VMA which needs paging, COW'ing or related OS ops. copy_*_user
does not do the access in any different way than a "manual" access or
memcpy does, it just adds a .fixup section that tells the do_page_fault
handler that it should not segfault the kernel itself if the copy takes a
big fault at any point, instead it should jump to the fixup which makes
the copy routine return an error message.
You're right, I remembered wrong.
(1) In a "top half" thread, can I now access this memory without the
access macros (since I know the address range is valid)?
The address is valid, the pages probably aren't. In fact, extending the
address space only creates read-only mappings to the global zeroed page
if I remember right.
But it does not matter that the pages aren't there physically, any kind of
access (including an access from kernel-mode) will bring about the same
COW/change-on-write mechanism as copy_to_user or a user-mode access would.
However these faults can let you sleep (swap-in, or swap-out to make
room for a COW page). That's defined for the uaccess macros, but might
come very unexpected with a memcpy. Unexpected sleeps alone can make a
crash if the surrounding code does not allow it.
It's a moot point anyway, memcpy with user space is illegal.
--
Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
On Wed, Nov 22, 2000 at 09:39:51PM +, Keir Fraser wrote:
> > The reason that everyone else uses copy_{to,from}_user is that there
> > is no way to guarantee that the userspace pointer is valid. That
> > memory may have been swapped out. The copy macros are prepared to
> > fault the memory in. The rest of the kernel is not.
> >
> > Jeff
>
> I may be wrong on this, but I thought that copy_{to,from}_user are
> only necessary if the address range you are accessing might cause a
> fault which Linux cannot handle (ie. one which would cause the
> application to segfault if it accessed that memory). If it is only a
> matter of paging the memory in (and you are _sure_ the address range is
> otherwise valid) I think the access macros are unnecessary. I would be
> *very* glad if someone could confirm this, or shoot me down. :)
It is wrong. copy_*_user handle the page faults, whether they are good
faults (swapped out, copy on write) or bad faults (illegal access).
Without these macros you get the "unable to handle kernel page fault"
oops message if a fault occurs.
> For instance, a kernel module I am writing allocates some memory in
> the current process's address space as follows:
>
> down(>mmap_sem);
> s->table = (void **)get_unmapped_area(0, SIZEOF_TABLE);
> if ( s->table != NULL )
> do_brk((unsigned long)s->table, SIZEOF_TABLE);
> up(>mmap_sem);
>
> Some questions:
> (1) In a "top half" thread, can I now access this memory without the
> access macros (since I know the address range is valid)?
The address is valid, the pages probably aren't. In fact, extending the
address space only creates read-only mappings to the global zeroed page
if I remember right.
> (2) Can I also access this memory from an interrupt/exception
> context, or must I lock it? (ie. can faults be handled from such
> a context)
You can't even use copy_*_user in this context (since the current user
space might be any process, even kernel threads that have no user space
at all).
For access to user memory from interrupt context at all and to access
user memory without the uaccess macros, you have to lock them down in
memory, with map_user_kiobuf(). This is only recommended if you want
hardware to DMA to/from buffers provided by user space.
> (3) Is the above code sensible at all, or barking? It took me a while
> to figure that the above would work, and I think/hope it is the
> most elegant way to share memory between kernel and a process.
It will fail quickly, probably taking the kernel down with it.
The most elegant way to share memory between user and kernel is to
allocate the memory in the kernel and map it to user space (by
implementing mmap on the kernel side for the file used for
communication).
--
Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Address translation
On Wed, Nov 22, 2000 at 09:39:51PM +, Keir Fraser wrote:
The reason that everyone else uses copy_{to,from}_user is that there
is no way to guarantee that the userspace pointer is valid. That
memory may have been swapped out. The copy macros are prepared to
fault the memory in. The rest of the kernel is not.
Jeff
I may be wrong on this, but I thought that copy_{to,from}_user are
only necessary if the address range you are accessing might cause a
fault which Linux cannot handle (ie. one which would cause the
application to segfault if it accessed that memory). If it is only a
matter of paging the memory in (and you are _sure_ the address range is
otherwise valid) I think the access macros are unnecessary. I would be
*very* glad if someone could confirm this, or shoot me down. :)
It is wrong. copy_*_user handle the page faults, whether they are good
faults (swapped out, copy on write) or bad faults (illegal access).
Without these macros you get the "unable to handle kernel page fault"
oops message if a fault occurs.
For instance, a kernel module I am writing allocates some memory in
the current process's address space as follows:
down(mm-mmap_sem);
s-table = (void **)get_unmapped_area(0, SIZEOF_TABLE);
if ( s-table != NULL )
do_brk((unsigned long)s-table, SIZEOF_TABLE);
up(mm-mmap_sem);
Some questions:
(1) In a "top half" thread, can I now access this memory without the
access macros (since I know the address range is valid)?
The address is valid, the pages probably aren't. In fact, extending the
address space only creates read-only mappings to the global zeroed page
if I remember right.
(2) Can I also access this memory from an interrupt/exception
context, or must I lock it? (ie. can faults be handled from such
a context)
You can't even use copy_*_user in this context (since the current user
space might be any process, even kernel threads that have no user space
at all).
For access to user memory from interrupt context at all and to access
user memory without the uaccess macros, you have to lock them down in
memory, with map_user_kiobuf(). This is only recommended if you want
hardware to DMA to/from buffers provided by user space.
(3) Is the above code sensible at all, or barking? It took me a while
to figure that the above would work, and I think/hope it is the
most elegant way to share memory between kernel and a process.
It will fail quickly, probably taking the kernel down with it.
The most elegant way to share memory between user and kernel is to
allocate the memory in the kernel and map it to user space (by
implementing mmap on the kernel side for the file used for
communication).
--
Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: can kernel memory allocated by kmalloc be swapped out??
On Sun, Sep 17, 2000 at 06:42:38PM +0530, [EMAIL PROTECTED] wrote: > hi everyone, > > suppose i allocate some kernel memory in a module by calling kmalloc, > can that memory be swapped out, for example in AIX even the kernel memory > which is allocated by rmalloc is swappable!! No, it isn't swappable. Neither is vmalloc()ed memory. The only swappable memory (i.e. either paged out to swap area or file) is mmap()ed memory. (mmap() isn't to be taken too literally, user space doesn't call mmap() for most of its stuff, but the kernel does call it (or one of the lower level primitives) for user allocated memory.) -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: can kernel memory allocated by kmalloc be swapped out??
On Sun, Sep 17, 2000 at 06:42:38PM +0530, [EMAIL PROTECTED] wrote: hi everyone, suppose i allocate some kernel memory in a module by calling kmalloc, can that memory be swapped out, for example in AIX even the kernel memory which is allocated by rmalloc is swappable!! No, it isn't swappable. Neither is vmalloc()ed memory. The only swappable memory (i.e. either paged out to swap area or file) is mmap()ed memory. (mmap() isn't to be taken too literally, user space doesn't call mmap() for most of its stuff, but the kernel does call it (or one of the lower level primitives) for user allocated memory.) -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote: > On 13 Sep 2000, Ralf Gerbig wrote: > > > * Chip Salzenberg writes: > > > > Hi Chip, > > > > > According to Ralf Gerbig: > > >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. > > > > > You've just made L-K's understatement of the day. > > > > [...] > > > > so I rest my case vs shrink wrap. > > > > Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I > recompiled the kernel source that they supplied. First, I just did > `make oldconfig` so I could duplicate the existing kernel. Well. > No such luck. There was no way in hell I could duplicate the kernel > that they supplied, with the sources that they supplied. And there > was no secret 'patch' directory either... I'm not sure (don't have a SuSE box right here) but I think they have separate packages for patched and unpatched kernel sources. I also remember their kernel patches are even separately stored somewhere. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Distro kernel patches (was Re: Linux 2.2.18pre4)
On Wed, Sep 13, 2000 at 05:31:17PM -0400, Richard B. Johnson wrote: On 13 Sep 2000, Ralf Gerbig wrote: * Chip Salzenberg writes: Hi Chip, According to Ralf Gerbig: but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels. You've just made L-K's understatement of the day. [...] so I rest my case vs shrink wrap. Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I recompiled the kernel source that they supplied. First, I just did `make oldconfig` so I could duplicate the existing kernel. Well. No such luck. There was no way in hell I could duplicate the kernel that they supplied, with the sources that they supplied. And there was no secret 'patch' directory either... I'm not sure (don't have a SuSE box right here) but I think they have separate packages for patched and unpatched kernel sources. I also remember their kernel patches are even separately stored somewhere. -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Bind Souce Code
On Wed, Sep 13, 2000 at 09:33:02AM +0800, Pan Renzi wrote: > This is a multi-part message in MIME format. No, it isn't. It just pretends to be. This is your second post to this list, which is about the Linux kernel and not about Bind. We can't answer your question, ask the appropriate people instead (try a mailing list about Bind, for starters). -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Bind Souce Code
On Wed, Sep 13, 2000 at 09:33:02AM +0800, Pan Renzi wrote: This is a multi-part message in MIME format. No, it isn't. It just pretends to be. This is your second post to this list, which is about the Linux kernel and not about Bind. We can't answer your question, ask the appropriate people instead (try a mailing list about Bind, for starters). -- Andreas E. Bombe [EMAIL PROTECTED]DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
