Re: [Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen
Dear Alex, Christian and others,
On Mon, Apr 10, 2017 at 3:50 AM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
> --- Comment #11 from Christian König (deathsim...@vodafone.de) ---
> Well bisecting which patch caused the break would be a good idea.
First of all, I hope you don't mind that I'm including my mom here, so
that she can follow how her computer is doing, or, rather, what I am
doing with her computer.
> To start that I suggest you try to compile kernel 4.4 by yourself first.
>
> That should also yield a temporary solution until we can narrow down the root
> cause.
I tried using Ubuntu's unpatched/precompiled kernels 4.2, 4.4, 4.8,
4.10 and 4.11-rc5 and, apparently, they now always show this message
*and* it frequently freezes to the point that no magic Sysrq keys
work, sometimes the caps lock kernel blinks and so on.
Booting with radeon.modeset=0 allows the computer to boot to the
desktop environment, but makes the CPU so hot when she plays her
flashplayer-based games that the kernel shows many messages of thermal
limit being reached and CPU speed being throttled.
Booting with radeon.runpm=0 still gets me all the error messages
listed in the subject (and present in the logs that I sent to
bugzilla), but the temperature *seems* to be slightly lower (not
enough testing was done with this configuration).
I don't know how to see/check what GPU is being used at a given time:
if the Intel GPU or if the AMD GPU...
So, given that the problem now seems to be present with all those
kernel versions that I tested, is it worthwhile to compile my own
kernels?
As before, I will try to do whatever I'm directed to.
Thanks a lot,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: [Bug 195231] Continuous messages of "*ERROR* UVD not responding, trying to reset the VCPU!!!" and frozen screen
Dear Alex and other developers,
On Thu, Apr 6, 2017 at 1:03 AM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=195231
>
> --- Comment #9 from Rogério Brito (rbr...@ime.usp.br) ---
> (In reply to Alex Deucher from comment #2)
>> Please attach your xorg log and dmesg output. Does appending radeon.runpm=0
>> on the kernel command line in grub help?
>
> Dear Alex and other developers, do you need any extra information from me? I
> will do my best to gather anything that may be helpful in fixing this bug.
I just installed Ubuntu's precompiled and unpatched kernel 4.11-rc5
and the messages of "UVD not responding" like in the subject persist,
also with the whole system hanging.
If I append radeon.runpm=0, the system does boot, but the messages are
still there. It is, though, taking ages to boot, compared to what it
used to be.
Once again, if anybody wants me to try any kernel, just tell me and I
will do my best.
I will update the information that I grab and/or those that people ask
me and put those at this bug on bugzilla
(https://bugzilla.kernel.org/show_bug.cgi?id=195231).
Thanks,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Multiple problems with the Linux kernel on an AMD desktop
Hi, Clemens and others.
On Nov 25 2016, Clemens Ladisch wrote:
> Rogério Brito wrote:
> > [ 130.007219] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
>
> The evbug module is intended for debugging; it dumps all input events
> into syslog. If you do not want these messages, do not load this module.
> (If it is loaded automatically, you have an actual bug.)
It *was* loaded automatically, and I didn't specifically asked it to be
loaded, but I'm not sure if other parts of userspace forced it to be
loaded. I will disable it, then.
Here is the relevant part of the config file:
,[ grep -i evbug /boot/config-4.9.0-040900rc6-generic ]
| CONFIG_INPUT_EVBUG=m
`----
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Multiple problems with the Linux kernel on an AMD desktop
Hi, Clemens and Borislav.
On Nov 25 2016, Clemens Ladisch wrote:
> Rogério Brito wrote:
> > * I have never been able to boot this computer of mine without the option
> > irqpoll---otherwise, I get the nobody cared message.
>
> The "nobody cared" message indicates that there were too many interrupts
> that no driver felt responsible for, so the kernel has disabled that
> interrupt vector. The irqpoll option is a workaround to get the devices
> on that interrupt vector to work, but it's not perfect.
Ah, great to know. I don't know if this is related or not, but I read
somewhere (don't remember where) that the machine may have performance
slightly reduced when irqpoll is used.
> It's possible that most of your problems are caused by the irqpoll option.
Excellent to know.
> What IRQ is the problematic one (see the "nobody cared" message)? What
> devices are connected to it (see /proc/interrupts)?
>From the dmesg log, the interrupt is 18.
Here is part from /proc/interrupts that contains interrupt 18 *without* irqpoll:
---
CPU0 CPU1 CPU2 CPU3
0: 47 0 0 0 IO-APIC 2-edge timer
1: 0 0 0 2 IO-APIC 1-edge i8042
7: 0 0 0 0 IO-APIC 7-edge
parport0
8: 0 0 0 1 IO-APIC 8-edge rtc0
9: 0 0 0 0 IO-APIC 9-fasteoi acpi
10: 0 0 0 0 IO-APIC 10-edge radeon
12: 0 0 0 4 IO-APIC 12-edge i8042
16: 0 96 4990 IO-APIC 16-fasteoi
ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel:card0
17: 0 2457 1140 IO-APIC 17-fasteoi
ehci_hcd:usb1
18: 1 11 43 99947 IO-APIC 18-fasteoi
ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 0 0 0 0 IO-APIC 19-fasteoi
ehci_hcd:usb2
22: 0 22169139 8731 IO-APIC 22-fasteoi
ahci[:00:11.0]
25: 0 0 11753 PCI-MSI 1048576-edge
eth0
(...)
---
Here is part from /proc/interrupts that contains interrupt 18 *with* irqpoll:
---
CPU0 CPU1 CPU2 CPU3
0: 46 0 0 0 IO-APIC 2-edge timer
1: 0 0 0 2 IO-APIC 1-edge i8042
7: 0 0 0 0 IO-APIC 7-edge
parport0
8: 0 0 0 1 IO-APIC 8-edge rtc0
9: 0 0 0 0 IO-APIC 9-fasteoi acpi
10: 0 0 0 0 IO-APIC 10-edge radeon
12: 0 0 0 4 IO-APIC 12-edge i8042
16: 0103 6983 IO-APIC 16-fasteoi
ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel:card0
17: 0588 0144 IO-APIC 17-fasteoi
ehci_hcd:usb1
18: 0 0 0705 IO-APIC 18-fasteoi
ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 0 0 0 0 IO-APIC 19-fasteoi
ehci_hcd:usb2
22: 0 18049 4 8540 IO-APIC 22-fasteoi
ahci[:00:11.0]
25: 0 0 0327 PCI-MSI 1048576-edge
eth0
(...)
---
I'm attaching both files to this message.
> Does the problem go away when you prevent the corresponding driver(s) from
> loading?
Since the OHCI_HCD driver is built-in (as opposed to a module), I don't know
how to disable it. I can try to recompile the kernel with it as a module and
rename it as some garbage, so that it doesn't get loaded...
Thanks a lot,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
CPU0 CPU1 CPU2 CPU3
0: 47 0 0 0 IO-APIC 2-edge timer
1: 0 0 0 2 IO-APIC 1-edge i8042
7: 0 0 0 0 IO-APIC 7-edge
parport0
8: 0 0 0 1 IO-APIC 8-edge rtc0
9: 0 0 0 0 IO-APIC 9-fasteoi acpi
10: 0 0 0 0 IO-APIC 10-edge radeon
12: 0 0 0 4 IO-APIC 12-edge i8042
16: 0 96
Re: Multiple problems with the Linux kernel on an AMD desktop
Dear Boris and Clemens,
First of all, thank you very much for your replies. They are very much
appreciated.
On Nov 25 2016, Borislav Petkov wrote:
> On Thu, Nov 24, 2016 at 09:39:57PM -0200, Rogério Brito wrote:
> > Before I go on describing the problems that I have, I want to say that I can
> > bisect the kernel, apply patches and give feedback for the problems that I
> > am seeing.
>
> Good. We're going to need them.
Great. I'm willing to do that.
In fact, I have quite a few computers that are not running Linux that well
at this moment and I guess that lack of report from final users (or,
perhaps, reports being lost in the way) prevents those problems from getting
fixed.
Ihope that my efforts will help other users to have fewer problems with
Linux on older machines, at least.
> Please checkout lates Linus kernel:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
>
> build it, boot it on your machine, catch dmesg and send it to me.
To speed things up a bit, I grabbed Ubuntu's precompiled 4.8 and 4.9-rc6
(without any patches on top of Linus's tree) and booted on this machine.
The scanner problem is still there with vanilla 4.8 (with the irqpoll
option), but is gone with vanilla 4.9-rc6 (with the irqpoll option).
I guess that backports of fixes to this (once detected) are needed for
-stable kernels that distributions are shipping with?
The other problems ("nobody cared" and the flood of evbug/lost xx rtc
interrupts messages) remain with 4.9-rc6.
Interestingly, for a layman like me:
* if I remove the irqpoll option, the "hpet1: lost xx rtc interrupts" messages
are gone, but I still get messages like
[ 130.007219] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 130.167191] evbug: Event. Dev: input6, Type: 4, Code: 4, Value: 458767
[ 130.167195] evbug: Event. Dev: input6, Type: 1, Code: 38, Value: 1
[ 130.167197] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 130.247174] evbug: Event. Dev: input6, Type: 4, Code: 4, Value: 458767
* if I keep the irqpoll option, I get both "hpet1: lost xx rtc interrupts"
AND the evbug messages remain.
I'm attaching the dmesg of 4.9-rc6 both with and without irqpoll to this
message.
I'm now going to chase the information regarding /proc/interrupts that
Clemens asked about.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
dmesg-4.9.0-040900rc6-generic-with-irqpoll-1480088522.log.gz
Description: application/gzip
dmesg-4.9.0-040900rc6-generic-without-irqpoll-1480087431.log.gz
Description: application/gzip
Multiple problems with the Linux kernel on an AMD desktop
373.527961] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 373.607943] evbug: Event. Dev: input6, Type: 4, Code: 4, Value:
458827
[ 373.607947] evbug: Event. Dev: input6, Type: 1, Code: 104, Value: 0
[ 373.607949] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 373.895924] evbug: Event. Dev: input6, Type: 4, Code: 4, Value:
458827
[ 373.895928] evbug: Event. Dev: input6, Type: 1, Code: 104, Value: 1
[ 373.895930] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 373.959913] evbug: Event. Dev: input6, Type: 4, Code: 4, Value:
458827
[ 373.959917] evbug: Event. Dev: input6, Type: 1, Code: 104, Value: 0
[ 373.959920] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 374.087908] evbug: Event. Dev: input6, Type: 4, Code: 4, Value:
458827
[ 374.087911] evbug: Event. Dev: input6, Type: 1, Code: 104, Value: 1
[ 374.087913] evbug: Event. Dev: input6, Type: 0, Code: 0, Value: 0
[ 374.199899] evbug: Event. Dev: input6, Type: 4, Code: 4, Value:
458827
(...)
I reported the problem above at
https://bugzilla.kernel.org/show_bug.cgi?id=120251 in June, when I was
running Debian's kernel 4.6.
I included many details there about my hardware configuration, but, of
course, I can copy them here in email for convenience.
* Besides *both* problems listed above, starting with Debian's kernel 4.8, I
am seeing a very strange problem: when I was scanning some documents on my
(USB) HP PSC 1610, it *always* hangs within about 15% of the work done.
I discovered this while, as a single father, scanning some spiderman
drawings to let my 4 y.o. boy, so that he could paint on them.
This is 100% reproducible with kernel 4.8 and, with kernel 4.7 (dropped
from Debian's next release), I don't have this 3rd problem.
Once again, I can bisect the kernel, apply patches and give feedback for the
problems that I am seeing. Just let me know what is necessary and I will do
what I'm instructed.
Please, keep me CC'ed as I'm not currently subscribed to the mailing lists.
Also, feel free to drop/adjust the list of recipients as appropriate.
Thanks a lot,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Sleep problems with kernels >= 2.6.21 on powerpc
Hi, Thanks, Michal. I didn't know who to include as the wizards of the matter. On Aug 27 2007, Michal Piotrowski wrote: > [Adding STR wizards to CC] > > On 26/08/07, Rogério Brito <[EMAIL PROTECTED]> wrote: > > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own > > kernel with just the necessary parts for my work (version 2.6.23-rc3 > > taken from kernel.org), then I can't make the machine sleep: when I > > press the button, it acts like if I had, in sequence, pressed anything > > to wake it up (say, like pressing shift). Things are getting now a little bit fishy. Before, I was using gnome and all the little daemons that come with it (even though I just prefer a plain window manager), but, as I mentioned before, it didn't matter if I pressed the power button on X or on a console. I had the gnomee power-thingy sounding like an alarm (an ambulance!) on me when I pressed the power button with Debian kernels 2.6.22, for instance. I compiled my own (this time, from kernel.org) 2.6.23-rc3, with many modules and subsystems removed (e.g., bluetooth, as this laptop doesn't have it) and I got the exact same behavior. If I booted, OTOH, with Debian's kernel 2.6.18, things were fine and the machine would go to sleep without any problems. I am now suspecting of some module that prevented the machine from going to sleep and I now using just a fluxbox as my window manager. This time, even with a 2.6.23-rc3 kernel (again, from kernel.org) the machine went to sleep normally. I did 13 compiles with git bisect and some of them were unsucessfuly compiled, which I am afraid that may miss the real cause if I tag them as being "bad" (which I did). (This was with just a bare minimum installation of Debian). The course of action that I am taking right now is to pull GNOME and see if my current 23-rc3 kernel has any problems and see which modules are loaded. If things progress well, I will incrementally include features on the kernel that I need (I left out, for instance, the Firewire subsystem, so that compilation wouldn't take more than an hour here, despite the fact that I do need Firewire support on the kernel) and see the point where things are not normal. Again, I am willing to test anything that is useful to getting PowerPC working as well as it should with the final 2.6.23 release. Please, don't hesitate to ask for any further information. Regards, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Sleep problems with kernels >= 2.6.21 on powerpc
Hi. Unfortunately, it seems that kernels later than 2.6.21 have problems letting my powerpc iBook (G3 processor) going to sleep (suspend to ram). The userland that I am using is a Debian testing (lenny) and the default kernel that comes with it is 2.6.22, with some patches applied and pbbuttonsd (as the daemon for making the machine sleep). With kernel 2.6.21, from Debian (and other earlier kernels), the symptoms that I see when I press the power button is that the machine goes to sleep and the led that indicates that the machine is sleeping is blinking normally. If I, on the other hand, use Debian's kernel 2.6.22 or compile my own kernel with just the necessary parts for my work (version 2.6.23-rc3 taken from kernel.org), then I can't make the machine sleep: when I press the button, it acts like if I had, in sequence, pressed anything to wake it up (say, like pressing shift). I have already grabbed Linus's git tree and I am willing to do some cycles of "git bisect" to discover the point where it stopped working. I just thought that others may have seen such behaviour before or, if not, that being informative about what I see is of use for debugging this. I would also appreciate any guidance on this as I wish kernel 2.6.23 to be working again on powerpc machines. Please, if any tests are required, don't hesitate to ask me and I will try to whatever is needed to restore the correct behaviour of sleep with the Linux kernel. I have copied mailing lists that I think that are relevant. If they aren't, then please let me know. I would also appreciate if I were kept on carbon copies as I am only subscribed to debian-powerpc at the moment. Regards, Rogério Brito. P.S.: It unfortunately doesn't matter if I switch to a console or if I am in X when I press the power button with recent kernels. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 return of the dreaded "nobody cared" message with a Promise Card
Hi, Alan. First of all, thank you very much for your usual kind responses to me. Second, let me apologize for not being able to reply earlier. :-( I hope that you have not lost interest in fixing this strange situation. I think that I can be speedier with the replies now and, if you wish, I can even go to an IRC channel so that we can exchange information faster, if you want. On Nov 29 2006, Alan wrote: > On Wed, 29 Nov 2006 04:01:30 -0200 > Rogério Brito <[EMAIL PROTECTED]> wrote: > > >> The problem is that whenever I plug the Quantum drive, I get stack > > traces like this one (with a bit of context, so that you can get sense of > > what I am talking about): > > Ok IRQ routing problem on what seems to be an external IRQ. Nice that you have at least identified a possibility. > > ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 > > PCI: setting IRQ 10 as level-triggered > > ACPI: PCI Interrupt :00:11.0[A] -> Link [LNKB] -> GSI 10 (level, low) > > -> IRQ 10 > > Do your working kernels also have ACPI enabled and what do they say > here ? I have always had ACPI enabled, but, as you asked me, I grabbed a -rc6-mm2 kernel and tried to pass irqpoll. The nice news is that it doesn't hang like vanilla -rc6 with "Uncompressing Linux...", but the unexpected side effect that I got is that none of my Ethernet devices work now. :-( I booted with both "irqpoll" and with "acpi=off irqpoll" and the results were the same. Without any of these options, the kernel boots (like with 2.6.18.x), but it stays there saying that the secondary channel is downgraded due to the lack of 80-pin cable and the drive that *has* an 80-pin cable starts showing "hde: lost interrupt" some times and, after, say, 5 minutes, it still has not completed the boot. :-( > Ok I have a guess here - what does 2.6.19-rc6-mm2 do ? I've been > working on fixing up the VIA IRQ routing bugs as it happens. full > dmesg of the work/fail cases and an lspci -vxxx would be useful so I > can see how the hardware thinks it is configured. Ok, it's quite late at night here and I will upload the dmesg of the 2.6.19-rc6-mm2 kernel (together with lspci -vxxx) to http://www.ime.usp.br/~rbrito/promise/ I will post the behaviour of other kernels as soon as I wake up and you wish. BTW, should I disable ACPI compilation entirely or is "acpi=off" sufficient in further tests? I can do whatever you tell me to... Oh, one thing that is possibly worth bringing up to you is that I have this "nobody cared" problem for some time now (I think that it goes back to several kernel revisions---say, dating back from the 2.6.10 era?). I don't know if git has anything imported from such earlier kernels, but I can bisect/binary search whatever is convenient. One thing that I will try to see if I can get my hands on is on a 80-ribbon cable for this drive, just to see if there are any changes in behaviour (is it worth me trying to find one?). Thank you very much, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The return of the dreaded "nobody cared" message with a Promise Card
Hi, Andrew, hi Alan, hi others. First of all, I would kindly ask you that you keep me in the Cc'ed messages. I'm currently finishing grades of (loads and loads) of students and I'm having a hard time keeping up with my health problems and real life work, let alone the traffic of lkml. Well, let me get straight to the problem. I have an Asus A7V (Classic) motherboard with a VIA KT133 chipset and it has the two usual VIA IDE controllers and two extra Promise PDC20265 controllers. Right now, my setup is the following (given advice that once Alan gave me, but he may not recall it): * hda: DVD+-RW burner; * hdc: Plain CD-ROM reader; * hde: Seagate ST3160021A (7200.??) drive; * hdg: QUANTUM FIREBALLlct15 30 drive. The problem is that whenever I plug the Quantum drive, I get stack traces like this one (with a bit of context, so that you can get sense of what I am talking about): - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ide1 at 0x170-0x177,0x376 on irq 15 PDC20265: IDE controller at PCI slot :00:11.0 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:11.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 PDC20265: chipset revision 2 PDC20265: ROM enabled at 0x3000 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:DMA, hdh:pio Probing IDE interface ide2... hde: ST3160021A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared (try booting with the "irqpoll" option) [] show_trace_log_lvl+0x58/0x16a [] show_trace+0xd/0x10 [] dump_stack+0x19/0x1b [] __report_bad_irq+0x2e/0x6f [] note_interrupt+0x19f/0x1d5 [] __do_IRQ+0xb5/0xeb [] do_IRQ+0x67/0x86 [] common_interrupt+0x1a/0x20 DWARF2 unwinder stuck at common_interrupt+0x1a/0x20 Leftover inexact backtrace: === handlers: [] (ide_intr+0x0/0x19b) Disabling IRQ #10 Warning: Secondary channel requires an 80-pin cable for operation. hdg reduced to Ultra33 mode. ide3 at 0x8000-0x8007,0x7802 on irq 10 hde: max request size: 128KiB hde: 312581808 sectors (160041 MB) w/2048KiB Cache, CHS=19457/255/63, UDMA(100) hde: cache flushes supported hde: hde1 hde2 hde3 hde4 hdg: max request size: 128KiB hdg: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(33) hdg: cache flushes not supported hdg: hdg1 hdg2 hdg3 hdg4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is what I get when I boot with a 2.6.18.3 (custom) kernel *AND* with the irqpoll option already enabled. The kernel 2.6.19-rc6 that I have here doesn't work at all if I pass the irqpoll option (it just freezes right at "Uncompressing Linux" nothing is displayed at least during a minute or so---I think that it hanged). Since Linus Torvalds once said something to the effect that "users that are willing to help with patches are worth their weight in gold", I would like to contribute here. :-) I am willing to do a git bisect to see which may be a problematic patch or not, but the "irq 10: nobody cared (try booting with the "irqpoll" option)" is one that I reported to Andrew quite some time ago (I thought that it had gone away), and it didn't manifest itself until I had to reuse this extra drive, since I am doing a work that is producing a lot of data. Please, if you want any further information, don't hesitate to ask. I can test patches that are even moderately invasive, since I'm talking backups of the vital data of my system with regularity. Regards and thank you very much for any help, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] [KORG] BitTorrents?
On Aug 29 2005, Maciej Soltysiak wrote: > Also checkout other things they post, including video lectures: > http://torrent.ibiblio.org Thank you so very much for this. This is indeed a quite valuable resource and being able to download via bittorrent is sometimes faster for some people and the fact that we can also contribute with a little bandwidth for other people just gives the feeling of giving something back to the community. Thanks for the pointer, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Fw: Oops with 2.6.13-rc6-mm2 and USB mouse
Hi, Andrew. I just tested the USB mouse with 2.6.13-rc6-mm2 and ACPI disabled (which, according to Linus, is one of the "usual suspects") and the problem still occurred. On the other hand, with kernel 2.6.13-rc5-mm1 (which I am running now), I didn't have any problems plugging and unplugging the mouse. Here are the messages I get in dmesg (2.6.13-rc5-mm1) after I plug/unplug the mouse: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - usb 1-1.2: new low speed USB device using uhci_hcd and address 4 input: USB HID v1.00 Mouse [USB Wheel Mouse] on usb-:00:04.2-1.2 usb 1-1.2: USB disconnect, address 4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Just thought you might like to know about this. If you want me to test any other version, please let me know. Thanks, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops with 2.6.13-rc6-mm2 and USB mouse
Hi there. I just got myself a new USB mouse and it seems that kernel 2.6.13-rc6-mm2 (which is the kernel I am using right now) doesn't like it. I get an Oops (attached to this message) and it suddenly stops working. I still don't know if this is reproducible or if it occurs with other kernels. Please let me know whatever information you'd like to have to chase this bug. Thank you very much, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ Linux version 2.6.13-rc6-mm2-1 ([EMAIL PROTECTED]) (gcc version 4.0.1 (Debian 4.0.1-2)) #1 Thu Aug 25 03:18:21 BRT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009e800 (usable) BIOS-e820: 0009e800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 17fec000 (usable) BIOS-e820: 17fec000 - 17fef000 (ACPI data) BIOS-e820: 17fef000 - 17fff000 (reserved) BIOS-e820: 17fff000 - 1800 (ACPI NVS) BIOS-e820: - 0001 (reserved) 383MB LOWMEM available. On node 0, present: 98284, spanned: 98284 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 94188 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f6a90 ACPI: RSDT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x17fec000 ACPI: FADT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x17fec080 ACPI: BOOT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x17fec040 ACPI: DSDT (v001 ASUS A7V 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 Allocating PCI resources starting at 1800 (gap: 1800:e7ff) Built 1 zonelists Initializing CPU#0 Kernel command line: auto BOOT_IMAGE=Linux root=2103 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1109.938 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 386332k/393136k available (1700k kernel code, 6264k reserved, 637k data, 128k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2221.23 BogoMIPS (lpj=1110619) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383f9ff c1c3f9ff CPU: After vendor identify, caps: 0383f9ff c1c3f9ff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After all inits, caps: 0383f9ff c1c3f9ff 0020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: AMD Duron(tm) Processor stepping 00 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0e20) softlockup thread 0 started up. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050729 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 Disabling VIA memory write queue (PCI ID 0305, rev 02): [55] 89 & 1f -> 09 Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report PCI: Bridge: :00:01.0 IO window: disabled. MEM window: dc80-dddf PREFETCH window: ddf0-dfff PCI: Setting latency timer of device :00:01.0 to 64 Simple Boot Flag at 0x3a set to 0x80 Machine check exception polling timer started. apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. Initializing Cryptographic API lp: driver loaded but no devices found Real Time Clock Driver v1.12 Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 128M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 PCI: setting IRQ 11 as l
Re: 2.6.13-rc6-mm1
Hi. Unfortunately, it seems that current kernels (including vanilla -rc kernels) don't compile correctly on ppc if I have APM emulation enabled, but PMU disabled (only CUDA enabled). Here is what I get from a compilation try: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - debian:~/kernel/linux# make vmlinux CHK include/linux/version.h make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date. CHK include/linux/compile.h CHK usr/initramfs_list CC sound/oss/dmasound/dmasound_awacs.o sound/oss/dmasound/dmasound_awacs.c:262: warning: 'struct pmu_sleep_notifier' declared inside parameter list sound/oss/dmasound/dmasound_awacs.c:262: warning: its scope is only this definition or declaration, which is probably not what you want sound/oss/dmasound/dmasound_awacs.c:263: error: variable 'awacs_sleep_notifier' has initializer but incomplete type sound/oss/dmasound/dmasound_awacs.c:264: warning: excess elements in struct initializer sound/oss/dmasound/dmasound_awacs.c:264: warning: (near initialization for 'awacs_sleep_notifier') sound/oss/dmasound/dmasound_awacs.c:264: error: 'SLEEP_LEVEL_SOUND' undeclared here (not in a function) sound/oss/dmasound/dmasound_awacs.c:264: warning: excess elements in struct initializer sound/oss/dmasound/dmasound_awacs.c:264: warning: (near initialization for 'awacs_sleep_notifier') sound/oss/dmasound/dmasound_awacs.c:1424: error: conflicting types for 'awacs_sleep_notify' sound/oss/dmasound/dmasound_awacs.c:262: error: previous declaration of 'awacs_sleep_notify' was here sound/oss/dmasound/dmasound_awacs.c: In function 'awacs_sleep_notify': sound/oss/dmasound/dmasound_awacs.c:1428: error: 'PBOOK_SLEEP_NOW' undeclared (first use in this function) sound/oss/dmasound/dmasound_awacs.c:1428: error: (Each undeclared identifier is reported only once sound/oss/dmasound/dmasound_awacs.c:1428: error: for each function it appears in.) sound/oss/dmasound/dmasound_awacs.c:1481: error: 'PBOOK_WAKE' undeclared (first use in this function) sound/oss/dmasound/dmasound_awacs.c:1552: error: 'PBOOK_SLEEP_OK' undeclared (first use in this function) sound/oss/dmasound/dmasound_awacs.c: In function 'dmasound_awacs_init': sound/oss/dmasound/dmasound_awacs.c:3057: warning: implicit declaration of function 'pmu_register_sleep_notifier' make[3]: *** [sound/oss/dmasound/dmasound_awacs.o] Error 1 make[2]: *** [sound/oss/dmasound] Error 2 make[1]: *** [sound/oss] Error 2 make: *** [sound] Error 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If I enable CONFIG_ADB_PMU, then it compiles fine. :-( Thanks in advance for any help, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-mm1
On Aug 21 2005, Andrew Morton wrote: > Rogério Brito <[EMAIL PROTECTED]> wrote: > > Unfortunately, it seems that current kernels (including vanilla -rc > > kernels) don't compile correctly on ppc if I have APM emulation > > enabled, but PMU disabled (only CUDA enabled). > > > > Here is what I get from a compilation try: (...) > > Could you send the .config please? Sure. I is attached to this message. Please let me know if I can help with any other information. Thanks, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc6-mm1-4.ow # Sun Aug 21 07:26:29 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor # CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E200 is not set # CONFIG_E500 is not set CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set # CONFIG_TAU is not set # CONFIG_KEXEC is not set # CONFIG_CPU_FREQ is not set # CONFIG_PPC601_SYNC_FIX is not set CONFIG_PM=y CONFIG_PPC_STD_MMU=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set # # Platform options # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_APUS is not set # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is not set # CONFIG_HDPU is not set # CONFIG_EV64260 is not set # CONFIG_LOPEC is not set # CONFIG_MVME5100 is not set # CONFIG_PPLUS is not set # CONFIG_PRPMC750 is not set # CONFIG_PRPMC800 is not set # CONFIG_SANDPOINT is not set # CONFIG_RADSTONE_PPC7D is not set # CONFIG_PAL4 is not set # CONFIG_GEMINI is not set # CONFIG_EST8260 is not set # CONFIG_SBC82xx is not set # CONFIG_SBS8260 is not set # CONFIG_RPX8260 is not set # CONFIG_TQM8260 is not set # CONFIG_ADS8272 is not set # CONFIG_PQ2FADS is not set # CONFIG_LITE5200 is not set # CONFIG_MPC834x_SYS is not set CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_PREP=y CONFIG_PPC_OF=y CONFIG_PPCBUG_NVRAM=y # CONFIG_SMP is not set # CONFIG_HIGHMEM is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PROC_DEVICETREE=y # CONFIG_PREP_RESIDUAL is not set # CONFIG_CMDLINE_BOOL is not set # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # # CONFIG_ISA is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # Advanced setup # # CONFIG_ADVANCED_OPTIONS is not set # # Default settings for advanced configuration options are used # CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_I
Re: 2.6.13-rc5-mm1
Thanks Andrew, for including the vfat speedup patch. It has really improved a lot the performance of access to directories having many subdirectories in an external Firewire HD that I have. I'd say that if others don't have problems with it, then it should be in 2.6.13, as far as I am concerned. BTW, everything is working fine with the sbp2/ieee1394 drivers that are in the mm tree. It seems that there are some issues with ALSA, though. I will report back as soon as I see if these are userland problems or not (it worked fine with vanilla 2.6.13-rc5). Thanks, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Jul 27 2005, Lee Revell wrote: > On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote: > > The OSS maestro driver works better on my old Armada E500 laptop. > > I tried ALSA after switching to 2.6, but the computer hung with > > 2.6.8.1 or 2.6.10 if I touched the volume buttons. > > Please test a newer ALSA version, like the one in 2.6.12. I have an Armada V300 laptop that uses the maestro2 chipset (and I wouldn't be surprised if your E500 used that very same chip) and it works fine with the ALSA provided in kernels since the 2.6.10-mm era (actually, I think it worked fine with even earlier kernels, but I am not sure). Just another datapoint, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Firewire/SBP2 and the -mm tree
On Jul 03 2005, Stefan Richter wrote: > Rogério Brito wrote: > >With 2.6.13-rc1-mm1, it works if I patch sbp2.[ch] *and* pass the > >disable_irm parameter. If I don't pass the parameter, I get the same > >strange behaviour as I did before. > > Thanks for the systematic tests. You're welcome. If I can be of any help, then please let me know. > >I have not yet tested with a vanilla 2.6.13-rc1-mm1 (i.e., without > >patching sbp2.[ch]) and with disable_irm=1. I can test this, if desired > >or any other thing that you may want me to test. > > We need to get it working without disable_irm. There seems to be an undesired side-effect when I use disable_irm: my PS/2 mouse stops working in X. :-( I have not paid attention to any changes in the dmesg output, but I didn't notice anything different from a regular boot. I can test it more as soon as I have some spare time. > I hope to have some spare time sooner or later to look closer into it. I > would get back to you if I come up with patches to try out or if somebody > else proposes a fix. I am, then, awaiting for any feedback from you or other linux1394 person. Thank you, Rogério. -- Rogério Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Serious problems with HFS+
On Mar 13 2005, Matt Mackall wrote: > I've noticed a few problems with HFS+ support in recent kernels on > another user's machine running Ubuntu (Warty) running 2.6.8.1-3-powerpc. I also saw some of the things that you reported with Debian proper (sarge). Unfortunately, I haven't been able to use my HFS+ formatted system with Linux for a while, I may do so, if necessary to fix the bugs. > I'm not in a position to extensively test or fix either of these problem > because of the fs tools situation so I'm just passing this on. I, OTOH, can test fixes on the next weekend, since I have a full backup scheduled for this week. > First, it reports inappropriate blocks to stat(2). It uses 4096 byte > blocks rather than 512 byte blocks which stat callers are expecting. > This seriously confuses du(1) (and me, for a bit). Looks like it may > be forgetting to set s_blocksize_bits. I had not noticed what are the size of the blocks that HFS+ seems to use, but indeed I saw both very confused du and ls outputs. I don't know what may be the cause. > Second, if an HFS+ filesystem mounted via Firewire or USB becomes > detached, the filesystem appears to continue working just fine. That's the only way that I am using a HFS+ fs (fia Firewire or USB), since the drive in question is in an enclosure. > I can find on the entire tree, despite memory pressure. I can even create > new files that continue to appear in directory listings! Writes to > such files succeed (they're async, of course) and the typical app is > none the wiser. It's only when apps attempt to read later that they > encounter problems. It turns out that various apps including scp > ignore IO errors on read and silently copy zero-filled files to the > destination. So I got this report as "why aren't the pictures I took > off my camera visible on my website?" I haven't seen this behaviour for lack of testing, but I will try to reproduce it with an HFS+ fs on a file mounted via loopback. > This is obviously a really nasty failure mode. At the very least, open > of new files should fail with -EIO. Preferably the fs should force a > read-only remount on IO errors. Given that the vast majority of HFS+ > filesystems Linux is likely to be used with are on hotpluggable media, > I think this FS should be marked EXPERIMENTAL until such integrity > problems are addressed. I agree. This is, indeed, very scary. Just another data point, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.6.11-rc4 libata-core (irq 30: nobody cared!)
First of all, thank you very much for your reply, Jeff. On Feb 26 2005, Jeff Garzik wrote: > "irq XX: nobody cared" is a screaming interrupt situation, which could > have 1001 causes. Ok, I didn't know that. > Normally it's something that "pci=biosirq" or "acpi=off" will fix, but > on occasion the driver itself is what needs fixing. Well, I already tried both of those options (and some others too) and nothing seems to make my kernel quiet regarding my Promise controller (just as a reminder, it is a PDC20265, embedded in my Asus A7V motherboard). If you want me to test any patches, feel free to contact me. Thanks, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: 2.6.11-rc4 libata-core (irq 30: nobody cared!)
On Feb 23 2005, Jeff Garzik wrote: > Does this patch do anything useful? > Jeff (...) The patch you posted seems to only affect people using SATA, right? BTW, just for clarity I'm seeing the message in a PATA environment (on i386) and Brian is seeing his problem with a SATA device on ppc. Thanks, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
On Feb 21 2005, Bartlomiej Zolnierkiewicz wrote: > On Sunday 20 February 2005 19:05, Rogério Brito wrote: > > I have already tried contacting the linux-ide mailing list as a CC to my > > earlier messages, but I got no response. I am including some details in > > this e-mail. I included Bartlomiej in the CC, as he is listed as general > > IDE maintainer in the MAINTAINERS file. > > Hi, Hi, Bartlomiej. > There is no need to cc: me 3x times, > I'm subscribed to linux-kernel and linux-ide > so I got your mail 5x times... I'm sorry for this. I didn't know which personal e-mail address was operational, since I saw many that you used. > If I don't reply it means that I'm busy doing other stuff. Ok, thank you for your feedback. I hope that you can find some time to help me with my system. I can provide you any information that you want. Just let me know and I will do my best to give you detailed information. Thank you very much, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
On Feb 20 2005, Matthias-Christian Ott wrote: > Rogério Brito wrote: > >I am willing to test any patch and configuration (let's call me a > >"guinea pig"), but I don't know what I should do. I have, OTOH, > >reported my problem many times in the past few days. :-( > > > >I will retry sending my message to the list once again, with the > >details (in my case, the message I get is "irq 10: nobody cared!" > >and it is regarding my primary HD on my secondary Promise PDC20265 > >controller). First of all, Matthias-Christian, thank you very much for your kind answer. I have already tried contacting the linux-ide mailing list as a CC to my earlier messages, but I got no response. I am including some details in this e-mail. I included Bartlomiej in the CC, as he is listed as general IDE maintainer in the MAINTAINERS file. > Report it to http://bugzilla.kernel.org/. Maybe you'll get help there. Thanks. I will try filing a bug on that system as soon as I get the reply to create my account there. (...) > You see it's very difficult to fix such irq problems because some factors > can cause such an error. Yes, I understand that. > Maybe contacting specific malinglists (e.g. for "broken" pci cards > the pci mailinglist, etc.), maintainers or developers would be more > efficient (cc the lkml) and solve your problem (faster), because > this people are specialists are this type of hardware (e.g. pci). > > What hardware is connect through irq 5? In my case, my problem is not with irq 5, but with irq 10, as I mentioned earlier. The situation is this: I have an Asus A7V motherboard with 2 VIA vt82c686a controllers and 2 Promise PDC20265 controllers. I recently bought myself a new DVD recorder and since Alan Cox told me[*] that the Promise controllers had problems with ATAPI devices, I decided to arrange my system this way: /dev/hda: the DVD recorder (VIA controller, master) /dev/hdc: an old CD recorder (VIA controller, master) /dev/hde: my first HD (Promise controller, master) /dev/hdg: my second HD (Promise controller, master) The Promise controller is able to control the HDs (which now have exclusive 80-pin cables) at their maximum, but I get the following stack trace if I have /dev/hdg turned on: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared! [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x4c/0x71 [] __do_IRQ+0x93/0xbd [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] probe_hwif+0x2da/0x366 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x88 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This is just an excerpt of the messages. I can provide much more details if I know what is relevant. I had already posted some old dmesg logs at my site <http://www.ime.usp.br/~rbrito/ide-problem/>, but this was before I got myself a second 80-ribbon cable (I expected that the problem would go away, but it didn't). Any other comments are more than welcome. Thanks in advance, Rogério Brito. [*] http://infocenter.guardiandigital.com/archive/linux-kernel/2004/Dec/2663.html -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11rc4: irq 5, nobody cared
On Feb 20 2005, Folkert van Heusden wrote: > My linux laptop says: > irq 5: nobody cared! (...) > Does anyone care? :-) Well, I'm getting similar stack traces with my system and those are sure scary, but it seems that my e-mails to the list are simply ignored, unfortunately. I am willing to test any patch and configuration (let's call me a "guinea pig"), but I don't know what I should do. I have, OTOH, reported my problem many times in the past few days. :-( I will retry sending my message to the list once again, with the details (in my case, the message I get is "irq 10: nobody cared!" and it is regarding my primary HD on my secondary Promise PDC20265 controller). Thanks for any help, Rogério. P.S.: I have already bought an 80-pin cable just for this drive in the hope that the message would go away, but it didn't. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.10: irq 12 nobody cared!
set_for_dma+0x216/0x227 [] pdc202xx_config_drive_xfer_rate+0x37/0x6c [] probe_hwif+0x34b/0x366 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x88 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 ide3 at 0x8000-0x8007,0x7802 on irq 10 hde: max request size: 128KiB hde: 25429824 sectors (13020 MB) w/418KiB Cache, CHS=25228/16/63, UDMA(33) hde: cache flushes not supported hde: hde1 hde2 hde3 hde4 hdg: max request size: 128KiB hdg: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(66) hdg: cache flushes not supported hdg: hdg1 hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 hdc: ATAPI 32X CD-ROM CD-R/RW drive, 4096kB Cache, UDMA(33) (...) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I already tried booting with options irqpoll, acpi=off, acpi=noirq etc, but none of these things made the problem go away. The only thing that made it really go away was when I disconnected the /dev/hdg drive. Then, no scary message is shown, but, of course, I need the /dev/hdg drive. :-( Here is what /proc/interrupts says about my computer: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CPU0 0:6083684 XT-PIC timer 1: 9 XT-PIC i8042 2: 0 XT-PIC cascade 7: 14134 XT-PIC parport0 8: 4 XT-PIC rtc 9: 321152 XT-PIC acpi, uhci_hcd, uhci_hcd, eth0, eth1 10: 662550 XT-PIC ide2, ide3, ohci1394 11: 30183 XT-PIC Ensoniq AudioPCI, [EMAIL PROTECTED]:1:0:0 12: 100706 XT-PIC i8042 14: 26 XT-PIC ide0 15: 26 XT-PIC ide1 NMI: 0 LOC:6083598 ERR: 31 MIS: 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Is there anything that I can do to make this error message go away? Please, don't hesitate to ask for any further information. Thank you very much in advance for any help, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 to get the maximum output from dmesg command
Srinivas G. <[EMAIL PROTECTED]> wrote: > How to get maximum output from dmesg command? > I am unable to see all my debug messages after loading my driver. > I think there is a restriction in displaying the dmesg output. There is indeed. > I saw in printk.c file under source directory. There I found LOG_BUF_LEN > is 16384. Sorry if this is obvious, but have you considered using the -s option of dmesg? Hope I understood it correctly, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Partially solved] Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
Hi, William. On Feb 12 2005, William Park wrote: > Your 'dmesg' says > Warning: Secondary channel requires an 80-pin cable for operation. > I assume it is. Well, I just finished compiling the 2.6.11-rc4 kernel and the problem persisted. This time, I enabled ACPI debugging and it indeed generates more details. Right after the problem persisted, I turned off the second HD (which was the master of the secondary channel of the Promise controller) and the problem automagically went away. :-( One other thing is that the BIOS still configures the drive as UDMA 4, but Linux downgrades that to UDMA 2. I'm not sure why. Using hdparm manually with "hdparm -c1 -u1 -d1 -X udma4 /dev/hde" enables things that the kernel doesn't and seems to be working wonderfully. I don't know what I should do right now. I have put the newer dmesg logs on <http://www.ime.usp.br/~rbrito/ide-problem/>. Should I contact anybody else? I do need the second drive on, though. I'm CC'ing Bartlomiej Zolnierkiewicz, as he is listed in the MAINTAINERS file as the IDE maintainer. Thanks for any comments and help, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
On Feb 12 2005, William Park wrote: > Do you have MSI on by any chance? (CONFIG_PCI_MSI) If so, try kernel > without it. My motherboard exhibits runaway IRQ with it. Ok, now I've just downloaded the -rc4 patch and while selecting the options to compile, I saw what MSI means. No, I didn't have MSI enabled. I guess tha I could try a compile with it enabled? I enabled the ACPI debugging messages, just in case it helps. I will now compile the new kernel. Let's see if the debugging messages help here. Hope this information is useful, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
On Feb 12 2005, William Park wrote: > On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote: > > To prevent the matters of loosing track of what is being done, I only > > changed one option at a time. I put the dmesg logs of all my attempts > > at <http://www.ime.usp.br/~rbrito/ide-problem/>. > > > > Please let me know if I can provide any other useful information. > > Your 'dmesg' says > Warning: Secondary channel requires an 80-pin cable for operation. > I assume it is. Indeed, I have two HDs plugged on the Promise controller. One of them (the first one) has a 80-pin cable and the bios configures it to use UDMA 4. Since I only have one 80-ribbon cable, the second HD uses a 40-ribbon cable and is configured as the master of the other channel of the Promise controller (to avoid having problems with the first one and to increase the performance, since IDE does not have the ability to "disconnect" devices). Perhaps that is the problem? I will try to turn off the second drive for a moment, but I guess that there shouldn't be such problems. One thing that is curious is that since both HDs are on different channels of the Promise controller (as masters), the BIOS configures the first one (with the 80-pin cable) as UDMA 4 and the second one (with the 40-pin cable) as UDMA 2. Then, when Linux boots, it downgrades both devices to UDMA 2, including the one with the 80-ribbon cable. Is that expected behaviour? > Do you have MSI on by any chance? (CONFIG_PCI_MSI) If so, try kernel > without it. My motherboard exhibits runaway IRQ with it. I don't know what MSI is (I only know of a manufacturer of motherboards called MSI), but my motherboard is an Asus A7V with chipset VIA KT133 (not the latter revision, VIA KT133A). Thank you very much for your help, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
On Feb 12 2005, William Park wrote: > This looks awefully like 'acpi' is on. If 'acpi=noirq' does not work, > then try 'pci=noacpi'. Hi, Willian. First of all, thank you very much for both your attention and help. Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just compiled and I tried using many boot parameters like "acpi=noirq", "irqpoll", "pci=noacpi", "acpi=off" and setting the BIOS of my motherboard to "Plug'n'Play OS = Yes" (instead of "Off", which is my default). To prevent the matters of loosing track of what is being done, I only changed one option at a time. I put the dmesg logs of all my attempts at <http://www.ime.usp.br/~rbrito/ide-problem/>. Please let me know if I can provide any other useful information. Thank you very much again for any help, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
On Feb 12 2005, William Park wrote: > On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote: > > For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's, > > some -mm trees and also -ac) I have been getting the message "irq 10: > > nobody cared!". > > Try 'acpi=noirq'. Unfortunately, I have already tried that and I still get stack traces like this one (this time, booted without any acpi-related option): - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Probing IDE interface ide1... hdc: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 PDC20265: IDE controller at PCI slot :00:11.0 PCI: :00:11.0 has unsupported PM cap regs version (1) ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared (try booting with the "irqpoll" option. [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x75/0x99 [] __do_IRQ+0x95/0xc1 [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] probe_hwif+0x2f7/0x383 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x92 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I can provide any information that is necessary about my system to fix the problem. I just finished compiling kernel 2.6.11-rc3-mm2 and I will report back if there is any difference. Thank you very much for any help, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Warnings when compiling apm
Hi there. For many kernel releases, including 2.6.11-rc3-mm2, I ve been getting warnings like the following when compiling the apm driver: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CC arch/i386/kernel/apm.o arch/i386/kernel/apm.c: In function `suspend': arch/i386/kernel/apm.c:1191: warning: `pm_send_all' is deprecated (declared at include/linux/pm.h:126) arch/i386/kernel/apm.c:1241: warning: `pm_send_all' is deprecated (declared at include/linux/pm.h:126) arch/i386/kernel/apm.c: In function `check_events': arch/i386/kernel/apm.c:1357: warning: `pm_send_all' is deprecated (declared at include/linux/pm.h:126) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Unfortunately, I read the code in pm.h and apm.c to see if I could fix the problem, but I am just not sure if killing the calls to pm_send_all is something that should be done or not (the function currently is just an inline function that returns 0). Similar things can be said about pm_register, pm_unregister, pm_unregister_all and pm_send. Thanks for any guidance, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
On Feb 05 2005, William Park wrote: > On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rogério Brito wrote: > > The message seems to be related to the Promise PDC20265 driver and it > > appeared right after I moved my HDs from my motherboard's VIA controllers > > to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a > > controllers and 2 Promise PDC20265 controllers. > > > > I already tried enabling and disabling ACPI, but it seems that the problem > > just doesn't go away. :-( > > Try 'acpi=noirq'. It did it for me (Abit VP6 dual-p3, Via VT82C694X, > Via VT82C686B). I tried to boot with acpi=noirq, but it didn't work for me. Here is the relevant part of the dmesg output (and the whole dmesg is attached to this message): - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (...) Kernel command line: BOOT_IMAGE=Linux root=2103 acpi=noirq (...) PDC20265: IDE controller at PCI slot :00:11.0 PCI: :00:11.0 has unsupported PM cap regs version (1) PCI: Found IRQ 10 for device :00:11.0 PCI: Sharing IRQ 10 with :00:0b.0 PDC20265: chipset revision 2 PDC20265: 100% native mode on irq 10 PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive ide2 at 0x8800-0x8807,0x8402 on irq 10 Probing IDE interface ide3... hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive irq 10: nobody cared (try booting with the "irqpoll" option. [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x75/0x99 [] __do_IRQ+0x95/0xc1 [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] probe_hwif+0x2f7/0x383 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x92 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 irq 10: nobody cared (try booting with the "irqpoll" option. [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x75/0x99 [] __do_IRQ+0x95/0xc1 [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] ide_config_drive_speed+0x168/0x30d [] pdc202xx_tune_chipset+0x38c/0x396 [] probe_hwif+0x341/0x383 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x92 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 Warning: Secondary channel requires an 80-pin cable for operation. hdg reduced to Ultra33 mode. irq 10: nobody cared (try booting with the "irqpoll" option. [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x75/0x99 [] __do_IRQ+0x95/0xc1 [] do_IRQ+0x19/0x24 [] common_interrupt+0x1a/0x20 [] __do_softirq+0x2c/0x7d [] do_softirq+0x22/0x26 [] do_IRQ+0x1e/0x24 [] common_interrupt+0x1a/0x20 [] enable_irq+0x88/0x8d [] ide_config_drive_speed+0x168/0x30d [] pdc202xx_tune_chipset+0x38c/0x396 [] config_chipset_for_dma+0x216/0x227 [] pdc202xx_config_drive_xfer_rate+0x37/0x6c [] probe_hwif+0x368/0x383 [] ata_attach+0xa3/0xbd [] probe_hwif_init_with_fixup+0x10/0x74 [] ide_setup_pci_device+0x72/0x7f [] pdc202xx_init_one+0x15/0x18 [] ide_scan_pcidev+0x34/0x59 [] ide_scan_pcibus+0x1c/0x92 [] probe_for_hwifs+0xb/0xd [] ide_init+0x44/0x59 [] do_initcalls+0x4b/0x99 [] init+0x0/0xce [] init+0x27/0xce [] kernel_thread_helper+0x5/0xb handlers: [] (ide_intr+0x0/0xee) Disabling IRQ #10 ide3 at 0x8000-0x8007,0x7802 on irq 10 hde: max request size: 128KiB hde: 25429824 sectors (13020 MB) w/418KiB Cache, CHS=25228/16/63, UDMA(33) hde: cache flushes not supported hde: hde1 hde2 hde3 hde4 hdg: max request size: 128KiB hdg: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(33) hdg: cache flushes not supported hdg: hdg1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So, it seems that I'm always getting this, whether I use acpi=off, acpi=noirq or the irqpoll options passed to the kernel. Would there be anything else that I should try? Thank you very much for the help, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.u
Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
On Feb 05 2005, Rogério Brito wrote: > I am including the dmesg log of my system with this message. (...) Ooops! Forgot to include the dmesg in the previous message. :-( Thanks again, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Linux version 2.6.11-rc3-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-5)) #1 Thu Feb 3 01:41:08 BRST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009e800 (usable) BIOS-e820: 0009e800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0ffec000 (usable) BIOS-e820: 0ffec000 - 0ffef000 (ACPI data) BIOS-e820: 0ffef000 - 0000 (reserved) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: - 0001 (reserved) 255MB LOWMEM available. On node 0 totalpages: 65516 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61420 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f6a90 ACPI: RSDT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec000 ACPI: FADT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec080 ACPI: BOOT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec040 ACPI: DSDT (v001 ASUS A7V 0x1000 MSFT 0x010b) @ 0x ACPI: PM-Timer IO Port: 0xe408 Built 1 zonelists Kernel command line: BOOT_IMAGE=Linux root=2103 irqpoll Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01201000) Initializing CPU#0 PID hash table entries: 1024 (order: 10, 16384 bytes) Detected 605.655 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 256196k/262064k available (1674k kernel code, 5308k reserved, 728k data, 140k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1196.03 BogoMIPS (lpj=598016) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0183f9ff c1c7f9ff CPU: After vendor identify, caps: 0183f9ff c1c7f9ff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After all inits, caps: 0183f9ff c1c7f9ff 0020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Duron(tm) Processor stepping 00 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0e20) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050125 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 13 devices PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to [EMAIL PROTECTED] ** so I can fix the driver. TC classifier action (bugs to netdev@oss.sgi.com cc [EMAIL PROTECTED]) pnp: 00:02: ioport range 0xe400-0xe47f could not be reserved pnp: 00:02: ioport range 0xe800-0xe80f has been reserved Simple Boot Flag at 0x3a set to 0x1 Machine check exception polling timer started. IA-32 Microcode Update Driver: v1.14 <[EMAIL PROTECTED]> apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. Initializing Cryptographic API PCI: Disabling Via external APIC routing ACPI: Power Button (FF) [PWRF] ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Processor [CPU0] (supports 16 throttling states) lp: driver loaded but no devices found Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA Twi
irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)
Dear developers, For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's, some -mm trees and also -ac) I have been getting the message "irq 10: nobody cared!". The message says that I should pass the irqpoll option to the kernel and even if I do, I still get the stack trace and the "irq 10: nobody cared!" message. :-( The message seems to be related to the Promise PDC20265 driver and it appeared right after I moved my HDs from my motherboard's VIA controllers to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a controllers and 2 Promise PDC20265 controllers. I already tried enabling and disabling ACPI, but it seems that the problem just doesn't go away. :-( I am including the dmesg log of my system with this message. I am CC'ing the linux-ide list, but I'm only subscribed to linux-kernel. I would appreciate CC's, if possible. Thank you very much for any help, Rogério. P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of kallsyms to see if the problem persists with this release. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
On Feb 05 2005, Jurriaan wrote: > From: Rogério Brito <[EMAIL PROTECTED]> > Date: Sat, Feb 05, 2005 at 04:10:18PM -0200 > > Inconsistent kallsyms data > > Try setting CONFIG_KALLSYMS_EXTRA_PASS > > make[1]: *** [vmlinux] Error 1 > > make[1]: Leaving directory `/usr/local/media/progs/linux/kernel/linux' > > make: *** [stamp-build] Error 2 > > Read what it says, and enable CONFIG_KALLSYMS_EXTRA_PASS, then try > again. Taken straight from the help option for CONFIG_KALLSYMS_EXTRA_PASS: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Always say N here unless you find a bug in kallsyms, which must be reported. KALLSYMS_EXTRA_PASS is only a temporary workaround while you wait for kallsyms to be fixed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I received, BTW, a message from Frank Denis saying that this is fixed in his -jedi1 patch. I will try it and report back the results that I come up with. Thanks for the feedback anyway, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
I'm having problems when trying to get 2.6.11-rc3-mm1 compiled. The build breaks with the message being thrown: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (...) LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make[1]: *** [vmlinux] Error 1 make[1]: Leaving directory `/usr/local/media/progs/linux/kernel/linux' make: *** [stamp-build] Error 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I'm compiling the kernel optimized for size (see attached .config) and I'm using a Debian sarge system, with GCC 3.3.5. In fact, I had this problem with 2.6.11-rc2-mm1 also, but I didn't have such problems with Linus' trees. OTOH, I would like to experiment with some goodies present in the -mm tree (like NFS ACL and FUSE). Thanks for any help, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc3-mm1-1 # Sat Feb 5 15:10:15 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMII=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_AC
irq 10: nobody cared! (bug with IDE, Promise PDC20265 controller)
Dear developers, I bought myself a DVD recorder yesterday and today I tried to install it in my system. I have an Asus A7V motherboard with a VIA KT133 chipset with 2 VIA IDE controllers and 2 Promise PDC20265 controllers. Since I already had a CD recorder, I decided to keep it and I tried to configure the things as: /dev/hda: the DVD recorder (in ide0, a VIA controller); /dev/hdc: the CD recorder (in ide1, also a VIA controller); /dev/hde: a 13GB HD (in ide2, a Promise PDC20265 controller); /dev/hdg: a 30GB HD (in ide3, also a PDC20265 controller). Unfortunately, right upon boot with my kernel 2.6.11-rc2, I got a stack trace saying that "irq 10: nobody cared!" and a whole lot of lines regarding to the promise controller. My kernel didn't have ACPI enabled (only APM). I then tried to compile a 2.6.11-rc2-mm2 kernel with ACPI enabled and that didn't solve the problem. Could anybody help, please? I don't know what is the relevant information, but I am attaching the dmesg of the 2.6.11-rc2-mm2 kernel. BTW, it suggested that I booted with the irqpoll option, which I did, but the problem persisted. If you need more information, please don't hesistate to ask. Thanks in advance for any help, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Linux version 2.6.11-rc2-mm2-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-5)) #1 Sun Jan 30 01:40:01 BRST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009e800 (usable) BIOS-e820: 0009e800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0ffec000 (usable) BIOS-e820: 0ffec000 - 0ffef000 (ACPI data) BIOS-e820: 0ffef000 - 0000 (reserved) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: - 0001 (reserved) 255MB LOWMEM available. On node 0 totalpages: 65516 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 61420 pages, LIFO batch:14 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f6a90 ACPI: RSDT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec000 ACPI: FADT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec080 ACPI: BOOT (v001 ASUS A7V 0x30303031 MSFT 0x31313031) @ 0x0ffec040 ACPI: DSDT (v001 ASUS A7V 0x1000 MSFT 0x010b) @ 0x Built 1 zonelists Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01201000) Initializing CPU#0 Kernel command line: BOOT_IMAGE=linux root=2103 irqpoll Misrouted IRQ fixup and polling support enabled. This may significantly impact system performance. PID hash table entries: 1024 (order: 10, 16384 bytes) Detected 605.414 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 255708k/262064k available (2137k kernel code, 5796k reserved, 721k data, 168k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1183.74 BogoMIPS (lpj=591872) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0183f9ff c1c7f9ff CPU: After vendor identify, caps: 0183f9ff c1c7f9ff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After all inits, caps: 0183f9ff c1c7f9ff 0020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Duron(tm) Processor stepping 00 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0e20) NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050125 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver f
Re: ppp in 2.6.11-rc2 Badness in local_bh_enable at kernel/softirq.c
On Jan 23 2005, Johnny Strom wrote: > I have the same problem with 2.6.11-rc2 I am using ppp with rp-pppoe-3.5 > it starts like this as soon as it brings upp the link. I am also seeing this "Badness in local_bh_enable at kernel/softirq.c:140" message spamming my logs. It is quite scary, might I add. I have only seen it with 2.6.11-rc2. Aside from that, the system seems to be working fine, but I only noticed this message for the last few hours. Before that, I run kernel 2.6.11-rc2 for 2 days straight and didn't see anything like that. It seems to have started when I first loaded the netfilter modules. I can provide more information. Just let me know what would be desired and I'll try to get it. Hope this helps, Rogério Brito. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/13] FAT: Return better error codes from vfat_valid_longname()
On Jan 18 2005, OGAWA Hirofumi wrote: > Rogério Brito <[EMAIL PROTECTED]> writes: > > Sorry for the stupid question, but is len guaranteed to be always greater > > than zero? > > Yes. That "len" was already checked in vfat_add_entry(). Sorry for the stupid question then. Thanks. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/13] FAT: Return better error codes from vfat_valid_longname()
On Jan 18 2005, OGAWA Hirofumi wrote:
> static int vfat_valid_longname(const unsigned char *name, unsigned int len)
> {
> - if (len && name[len-1] == ' ')
> - return 0;
> + if (name[len - 1] == ' ')
> + return -EINVAL;
Sorry for the stupid question, but is len guaranteed to be always greater
than zero?
Otherwise, I think that the test with len would be warranted. And, if that
is the case, wouldn't it be better to have it explicitly say if (len > 0...)?
Just curious. And sorry again for the stupid question. But as Knuth says,
"premature optimization is the root of all evil".
Perhaps I'm way too much into proving invariants of algorithms. :-)
Thanks for your work, Rogério.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Testing optimize-for-size suitability?
On Jan 16 2005, Arjan van de Ven wrote: > On Sun, 2005-01-16 at 10:40 -0500, Steve Snyder wrote: > > Is there a benchmark or set of benchmarks that would allow me to test > > the suitability of the CONFIG_CC_OPTIMIZE_FOR_SIZE kernel config > > option? > > it also saves 400 kb of memory that can be used by the pagecache now... > that doesn't show in a microbenchmark but it's a quite sizable gain if > you remember that a disk seek is 10msec..that is a LOT of cpu cycles.. Since I'm using a Duron 600MHz (the lowest model, AFAIK), I decided to compile a new kernel with the -Os option. Despite the scary warning on the help, it seems to be working fine for the first few moments with Debian's testing gcc (3.3.5). I haven't noticed any other improvement, but I guess that more memory available to applications would never hurt (as long as stability is preserved). I will also try to compile other applications (like Firefox), since my main memory is so limited and the small cache of my processor would surely appreciate it. Perhaps it is time to give the tiny-linux project a try to see what other optimizations I can achieve. Just another data point, Rogério. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
