Re: b44: regression in 2.6.22 (resend)
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote: > > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution > > > Timer, but the high ping problem is still there. > > > > Hmm, that's mysterious. Wild guess is that highres exposes the hidden > > "feature" in a different way than rc2-mm1 does. > > I think the bug in 2.6.21/22-rc3 is a different one that the one in > 2.6.22-rc2-mm1, but that's also only a wild guess :) > > I'll explain this a bit: > In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels for > some time. With this driver and High Resolution Timer turned on I get > problems using iperf. The problems are that the systems becomes really slow > and unresponsive. Michael Buesch thought this could be an IRQ storm which > sounds logical to me. This bug did never happen to me before I startet the > iperf test. Can you please apply http://www.tglx.de/projects/hrtimers/2.6.22-rc3/patch-2.6.22-rc3-hrt1.patch on top of rc3 and check, whether it has any effect on your problem. > The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb > spilt. It's independed wether High Resolution Timer is turned on or off I > always get very varying and high ping times. The iperf-test doesn't show the > problems from 2.6.21/22-rc3. Neither with nor without highres ? tglx Neither with nor without Gleixner ? Neither with nor without Buesch ? Neither with nor without Miller ? Neither with nor without Kyle ? Neither with nor without ? Neither with nor without would-like-to-spare time hackers ? Neither with nor without profile neurotic would-like-to-copyright owners ? ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: b44: regression in 2.6.22
On Monday 28 May 2007, Michael Buesch wrote: > Can you also test the following patch? > I think there's a bug in b44 that is doesn't properly discard > shared IRQs, so it might possibly generate a NAPI storm, dunno. > Worth a try. > > Index: linux-2.6.22-rc3/drivers/net/b44.c > === > --- linux-2.6.22-rc3.orig/drivers/net/b44.c 2007-05-27 23:01:44.0 > +0200 +++ linux-2.6.22-rc3/drivers/net/b44.c 2007-05-28 12:48:27.0 > +0200 @@ -911,6 +911,8 @@ static irqreturn_t b44_interrupt(int irq > spin_lock(>lock); > > istat = br32(bp, B44_ISTAT); > + if (istat == 0x) > + goto out; /* Shared IRQ not for us */ > imask = br32(bp, B44_IMASK); > > /* The interrupt mask register controls which interrupt bits > @@ -942,6 +944,7 @@ irq_ack: > bw32(bp, B44_ISTAT, istat); > br32(bp, B44_ISTAT); > } > +out: > spin_unlock(>lock); > return IRQ_RETVAL(handled); > } I did try this patch on a affected kernel, but I didn't notice any big difference. Perhaps the kernel is a bit less slow during the test, but It's hard to tell. Maxi I tried that one also, but it did not help to solve the real problem. The real problem is the b44 -> b44-ssb-port in 2.6.22-rc2-mm1. This port was not done correctly, as my bcm4401 runs fine with all 2.6 kernels except 2.6.22-rc2-mm1. I also tried to load the two modules that way: modprobe ssb debug=4 modprobe b44 debug=4 Unfortunately those two modules do not understand those command line parameters. I even reverted significant parts of module b44.h (i. e. the backplane definitions). But that did not help either. In so far the changes for b44.c in kernel 2.6.22-rc2-mm1 are definitely responsible for the fact that my bcm4401 controller refuses to work. Cheers Uwe P. S.: I am basically not against those ports like the above mentioned one. But if they are done they at least should be done more severe and correct. As this port is a deep cut into the architecture, it would be very helpful to make the two new modules understand debug command line parameters. Just to somplify troubleshooting. You cannot rip out code of one module, attempt to do a port, and afterwards jump around crying: "For me it works - what can I do?" You moreover cannot chase bug reporters to test 3 different developper kernels containing the same code expecting that there will be a real result to help resolve the real issue. You moreover cannot accuse bug reporters for typo errors in DNS server, for the ACPI system to be buggy etc. This is no professional bug handling, but it is just wasting time and nerves due to lack of concept how to resolve the real issue (i. BAD b44 --> b44-ssb port). Hint: Please everyone reading this see the following threads for positive examples how bug reports are to be resolved: A. the sis900.c Oops (before kernel 2.6.21.2) B. The "alsa architecture broken in parts" issue Those are only 2 examples on how to resolve bug report issues in a real sovereign and sophisticated manner. ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: b44: regression in 2.6.22
On Monday 28 May 2007, Michael Buesch wrote: Can you also test the following patch? I think there's a bug in b44 that is doesn't properly discard shared IRQs, so it might possibly generate a NAPI storm, dunno. Worth a try. Index: linux-2.6.22-rc3/drivers/net/b44.c === --- linux-2.6.22-rc3.orig/drivers/net/b44.c 2007-05-27 23:01:44.0 +0200 +++ linux-2.6.22-rc3/drivers/net/b44.c 2007-05-28 12:48:27.0 +0200 @@ -911,6 +911,8 @@ static irqreturn_t b44_interrupt(int irq spin_lock(bp-lock); istat = br32(bp, B44_ISTAT); + if (istat == 0x) + goto out; /* Shared IRQ not for us */ imask = br32(bp, B44_IMASK); /* The interrupt mask register controls which interrupt bits @@ -942,6 +944,7 @@ irq_ack: bw32(bp, B44_ISTAT, istat); br32(bp, B44_ISTAT); } +out: spin_unlock(bp-lock); return IRQ_RETVAL(handled); } I did try this patch on a affected kernel, but I didn't notice any big difference. Perhaps the kernel is a bit less slow during the test, but It's hard to tell. Maxi I tried that one also, but it did not help to solve the real problem. The real problem is the b44 - b44-ssb-port in 2.6.22-rc2-mm1. This port was not done correctly, as my bcm4401 runs fine with all 2.6 kernels except 2.6.22-rc2-mm1. I also tried to load the two modules that way: modprobe ssb debug=4 modprobe b44 debug=4 Unfortunately those two modules do not understand those command line parameters. I even reverted significant parts of module b44.h (i. e. the backplane definitions). But that did not help either. In so far the changes for b44.c in kernel 2.6.22-rc2-mm1 are definitely responsible for the fact that my bcm4401 controller refuses to work. Cheers Uwe P. S.: I am basically not against those ports like the above mentioned one. But if they are done they at least should be done more severe and correct. As this port is a deep cut into the architecture, it would be very helpful to make the two new modules understand debug command line parameters. Just to somplify troubleshooting. You cannot rip out code of one module, attempt to do a port, and afterwards jump around crying: For me it works - what can I do? You moreover cannot chase bug reporters to test 3 different developper kernels containing the same code expecting that there will be a real result to help resolve the real issue. You moreover cannot accuse bug reporters for typo errors in DNS server, for the ACPI system to be buggy etc. This is no professional bug handling, but it is just wasting time and nerves due to lack of concept how to resolve the real issue (i. BAD b44 -- b44-ssb port). Hint: Please everyone reading this see the following threads for positive examples how bug reports are to be resolved: A. the sis900.c Oops (before kernel 2.6.21.2) B. The alsa architecture broken in parts issue Those are only 2 examples on how to resolve bug report issues in a real sovereign and sophisticated manner. ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: b44: regression in 2.6.22 (resend)
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote: I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution Timer, but the high ping problem is still there. Hmm, that's mysterious. Wild guess is that highres exposes the hidden feature in a different way than rc2-mm1 does. I think the bug in 2.6.21/22-rc3 is a different one that the one in 2.6.22-rc2-mm1, but that's also only a wild guess :) I'll explain this a bit: In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels for some time. With this driver and High Resolution Timer turned on I get problems using iperf. The problems are that the systems becomes really slow and unresponsive. Michael Buesch thought this could be an IRQ storm which sounds logical to me. This bug did never happen to me before I startet the iperf test. Can you please apply http://www.tglx.de/projects/hrtimers/2.6.22-rc3/patch-2.6.22-rc3-hrt1.patch on top of rc3 and check, whether it has any effect on your problem. The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb spilt. It's independed wether High Resolution Timer is turned on or off I always get very varying and high ping times. The iperf-test doesn't show the problems from 2.6.21/22-rc3. Neither with nor without highres ? tglx Neither with nor without Gleixner ? Neither with nor without Buesch ? Neither with nor without Miller ? Neither with nor without Kyle ? Neither with nor without ? Neither with nor without would-like-to-spare time hackers ? Neither with nor without profile neurotic would-like-to-copyright owners ? ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 23:52 schrieben Sie:
> On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > > Uwe, please try the following patch:
> > > > >
> > > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > > ===
> > > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> > > > > 18:09:50.0 +0200 +++
> > > > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit
> > > > > b44_init_one(struct printk("%2.2x%c", dev->dev_addr[i],
> > > > > i == 5 ? '\n' : ':');
> > > > >
> > > > > +#if 0
> > > > > /* Initialize phy */
> > > > > spin_lock_irq(>lock);
> > > > > b44_chip_reset(bp);
> > > > > spin_unlock_irq(>lock);
> > > > > +#endif
> > > > >
> > > > > return 0;
> > > >
> > > > Against what kernel please?
> > > > Just try to be a bit more eloquent, man!
> > >
> > > Against a kernel which does not work for you, of course.
> > >
> > > Sometimes I wonder... (no better not say that).
> >
> > YES! And I wonder TOO, definitely!
> >
> > Quand meme (now, if you do not speak french: Above all that), I applied
> > your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to
> > get your "dream" being fulfilled!
> >
> > Result is: No change!
> > Non-functionable b44-device at all!
> >
> > Hint: Although being a "non-hacker" or "non-developer" I do have stepped
> > across some experienced developer people who at least added some code to
> > make their modules function in the following way:
> >
> > modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or
> > debug=6)
> >
> > In so far, if you continue to state that debugging is nothing but
> > guessing around wildly you are definitely wrong, showing us all your
> > missing code hacker experience. If you DO continue like this every step
> > will be a torture not only for me but for the reading folks as well.
> >
> > But every human being is here to learn and develop: In so far I am very
> > optimistic!
> >
> > Apart from the Kconfig chaos that seems to be subordinate in your
> > personal rating scale, you at least could have added some functions like
> > the above mentioned functions.
> >
> > The fact that you simply ignored to imply those functions and continue to
> > call other people dumb shows exactly how small and humble you are.
> >
> > Apart from that:
> > The message that you rooted to my place was no "proof" at all for any
> > kind of disfunctionality or compatibility issue!
> >
> > In that message the lack of performance of the "enclosed" or "old"
> > or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the
> > one ripped by you personally into two modules called b44 and ssb.
> >
> > In so far I would deeply appreciate you personally to stick to the facts
> > in your personal lack of knowledge about the b44 driver instead of
> > playing bad politics against other people like me and others.
> >
> >
> > Hello my dear Andrew Morton,
> >
> > Could you please do me and the rest of the world two favours?
> >
> > A. Rip Michael Buesches code out of the mm-tree
> >
> > B. Give Michael Buesch a fair chance to revise his disfunctionable code
> > outside the mm-tree and / or the vanilla mainline.
> >
> > Side note for the what and why:
> >
> > I like to help avoid dangers by testing the mm-tree.
> > BUT:
> >
> > If real debugging conforms to nothing but guessing around wildly let me
> > tell you that I do not appreciate to be part of that torture due to the
> > lack of experience of some German spare time hacker.
> >
> > A: proven by facts not knowing or even wanting to know how to imply
> > appropriate functionable debug parametres in his driver code
> >
> > B: non-cooperative as far as Kconfig help features are concerned (i. E.
> > help to understand the issues for users
> >
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 23:52 schrieben Sie: On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote: Am Samstag, 26. Mai 2007 21:49 schrieben Sie: On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote: Am Samstag, 26. Mai 2007 21:19 schrieben Sie: Uwe, please try the following patch: Index: bu3sch-wireless-dev/drivers/net/b44.c === --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18 18:09:50.0 +0200 +++ bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0 +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct printk(%2.2x%c, dev-dev_addr[i], i == 5 ? '\n' : ':'); +#if 0 /* Initialize phy */ spin_lock_irq(bp-lock); b44_chip_reset(bp); spin_unlock_irq(bp-lock); +#endif return 0; Against what kernel please? Just try to be a bit more eloquent, man! Against a kernel which does not work for you, of course. Sometimes I wonder... (no better not say that). YES! And I wonder TOO, definitely! Quand meme (now, if you do not speak french: Above all that), I applied your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get your dream being fulfilled! Result is: No change! Non-functionable b44-device at all! Hint: Although being a non-hacker or non-developer I do have stepped across some experienced developer people who at least added some code to make their modules function in the following way: modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6) In so far, if you continue to state that debugging is nothing but guessing around wildly you are definitely wrong, showing us all your missing code hacker experience. If you DO continue like this every step will be a torture not only for me but for the reading folks as well. But every human being is here to learn and develop: In so far I am very optimistic! Apart from the Kconfig chaos that seems to be subordinate in your personal rating scale, you at least could have added some functions like the above mentioned functions. The fact that you simply ignored to imply those functions and continue to call other people dumb shows exactly how small and humble you are. Apart from that: The message that you rooted to my place was no proof at all for any kind of disfunctionality or compatibility issue! In that message the lack of performance of the enclosed or old or complete b44 module (i. e. PCI-only module) was criticised, NOT the one ripped by you personally into two modules called b44 and ssb. In so far I would deeply appreciate you personally to stick to the facts in your personal lack of knowledge about the b44 driver instead of playing bad politics against other people like me and others. Hello my dear Andrew Morton, Could you please do me and the rest of the world two favours? A. Rip Michael Buesches code out of the mm-tree B. Give Michael Buesch a fair chance to revise his disfunctionable code outside the mm-tree and / or the vanilla mainline. Side note for the what and why: I like to help avoid dangers by testing the mm-tree. BUT: If real debugging conforms to nothing but guessing around wildly let me tell you that I do not appreciate to be part of that torture due to the lack of experience of some German spare time hacker. A: proven by facts not knowing or even wanting to know how to imply appropriate functionable debug parametres in his driver code B: non-cooperative as far as Kconfig help features are concerned (i. E. help to understand the issues for users C: calling all people simply dumb who do not know about his personal issues at all Thank you, Andrew Morton! You are real fine! Everyone just needs to cool down. And you both (Uwe and Michael) just need to try debugging the problem. Abstracting the SSB code into a library is clearly the correct solution, rather than having the same code in two separate places. The whole _point_ of having code in various trees (wireless, mm, etc) is to find these bugs before the patches hit mainline. Even testing on 3 machines may not uncover subtle bugs (for example, different behavior on different silicon revisions, especially in reverse-engineered parts), yes, and to simplify that you need additional commandline parametres (debug=1,2,3,4,5 f. ex.). Those debug levels provide: 1. different verbose levels of printed output, sent to specific logs like kern.log for example 2. different hexadecimal outprints who show what sub-part of the driver is working as expected and what part is not 3. if the driver is loaded correctly but refuses to work as expected while the traditional one without outsourced ssb backplane works as expected there must
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 23:52 schrieben Sie:
> On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > > Uwe, please try the following patch:
> > > > >
> > > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > > ===
> > > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> > > > > 18:09:50.0 +0200 +++
> > > > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit
> > > > > b44_init_one(struct printk("%2.2x%c", dev->dev_addr[i],
> > > > > i == 5 ? '\n' : ':');
> > > > >
> > > > > +#if 0
> > > > > /* Initialize phy */
> > > > > spin_lock_irq(>lock);
> > > > > b44_chip_reset(bp);
> > > > > spin_unlock_irq(>lock);
> > > > > +#endif
> > > > >
> > > > > return 0;
> > > >
> > > > Against what kernel please?
> > > > Just try to be a bit more eloquent, man!
> > >
> > > Against a kernel which does not work for you, of course.
> > >
> > > Sometimes I wonder... (no better not say that).
> >
> > YES! And I wonder TOO, definitely!
> >
> > Quand meme (now, if you do not speak french: Above all that), I applied
> > your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to
> > get your "dream" being fulfilled!
> >
> > Result is: No change!
> > Non-functionable b44-device at all!
> >
> > Hint: Although being a "non-hacker" or "non-developer" I do have stepped
> > across some experienced developer people who at least added some code to
> > make their modules function in the following way:
> >
> > modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or
> > debug=6)
> >
> > In so far, if you continue to state that debugging is nothing but
> > guessing around wildly you are definitely wrong, showing us all your
> > missing code hacker experience. If you DO continue like this every step
> > will be a torture not only for me but for the reading folks as well.
> >
> > But every human being is here to learn and develop: In so far I am very
> > optimistic!
> >
> > Apart from the Kconfig chaos that seems to be subordinate in your
> > personal rating scale, you at least could have added some functions like
> > the above mentioned functions.
> >
> > The fact that you simply ignored to imply those functions and continue to
> > call other people dumb shows exactly how small and humble you are.
> >
> > Apart from that:
> > The message that you rooted to my place was no "proof" at all for any
> > kind of disfunctionality or compatibility issue!
> >
> > In that message the lack of performance of the "enclosed" or "old"
> > or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the
> > one ripped by you personally into two modules called b44 and ssb.
> >
> > In so far I would deeply appreciate you personally to stick to the facts
> > in your personal lack of knowledge about the b44 driver instead of
> > playing bad politics against other people like me and others.
> >
> >
> > Hello my dear Andrew Morton,
> >
> > Could you please do me and the rest of the world two favours?
> >
> > A. Rip Michael Buesches code out of the mm-tree
> >
> > B. Give Michael Buesch a fair chance to revise his disfunctionable code
> > outside the mm-tree and / or the vanilla mainline.
> >
> > Side note for the what and why:
> >
> > I like to help avoid dangers by testing the mm-tree.
> > BUT:
> >
> > If real debugging conforms to nothing but guessing around wildly let me
> > tell you that I do not appreciate to be part of that torture due to the
> > lack of experience of some German spare time hacker.
> >
> > A: proven by facts not knowing or even wanting to know how to imply
> > appropriate functionable debug parametres in his driver code
> >
> > B: non-cooperative as far as Kconfig help features are concerned (i. E.
> > help to understand the issues for users
> >
>
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > Uwe, please try the following patch:
> > >
> > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > ===
> > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> > > 18:09:50.0 +0200 +++
> > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0
> > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> > > printk("%2.2x%c", dev->dev_addr[i],
> > > i == 5 ? '\n' : ':');
> > >
> > > +#if 0
> > > /* Initialize phy */
> > > spin_lock_irq(>lock);
> > > b44_chip_reset(bp);
> > > spin_unlock_irq(>lock);
> > > +#endif
> > >
> > > return 0;
> >
> > Against what kernel please?
> > Just try to be a bit more eloquent, man!
>
> Against a kernel which does not work for you, of course.
>
> Sometimes I wonder... (no better not say that).
YES! And I wonder TOO, definitely!
Quand meme (now, if you do not speak french: Above all that), I applied your
patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get
your "dream" being fulfilled!
Result is: No change!
Non-functionable b44-device at all!
Hint: Although being a "non-hacker" or "non-developer" I do have stepped
across some experienced developer people who at least added some code to make
their modules function in the following way:
modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6)
In so far, if you continue to state that debugging is nothing but guessing
around wildly you are definitely wrong, showing us all your missing code
hacker experience. If you DO continue like this every step will be a torture
not only for me but for the reading folks as well.
But every human being is here to learn and develop: In so far I am very
optimistic!
Apart from the Kconfig chaos that seems to be subordinate in your personal
rating scale, you at least could have added some functions like the above
mentioned functions.
The fact that you simply ignored to imply those functions and continue to call
other people dumb shows exactly how small and humble you are.
Apart from that:
The message that you rooted to my place was no "proof" at all for any kind of
disfunctionality or compatibility issue!
In that message the lack of performance of the "enclosed" or "old"
or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one
ripped by you personally into two modules called b44 and ssb.
In so far I would deeply appreciate you personally to stick to the facts in
your personal lack of knowledge about the b44 driver instead of playing bad
politics against other people like me and others.
Hello my dear Andrew Morton,
Could you please do me and the rest of the world two favours?
A. Rip Michael Buesches code out of the mm-tree
B. Give Michael Buesch a fair chance to revise his disfunctionable code
outside the mm-tree and / or the vanilla mainline.
Side note for the what and why:
I like to help avoid dangers by testing the mm-tree.
BUT:
If real debugging conforms to nothing but guessing around wildly let me tell
you that I do not appreciate to be part of that torture due to the lack of
experience of some German spare time hacker.
A: proven by facts not knowing or even wanting to know how to imply
appropriate functionable debug parametres in his driver code
B: non-cooperative as far as Kconfig help features are concerned (i. E. help
to understand the issues for users
C: calling all people simply dumb who do not know about his personal issues at
all
Thank you, Andrew Morton! You are real fine!
Sincerely
Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:57 schrieben Sie: > Uwe Bugla wrote: > > OK, applied this one against 2.6.22-rc3, assuming a typo error by you, > > Andrew. > > > > Result is: No change: non functionable b44 device! > > Could you please send the following: > > 1. the output of lsmod from the non-functioning kernel Nonsense! As I stated already, both modules (i. e. b44 and ssb) are loaded correctly. So please read the thread before you post that, not vice versa! > > 2. the output of dmesg from the non-functioning kernel > > 3. your .config used to create your non-functioning kernel. > They are already in the thread. So please leave me alone with those lazy hints! Read bfore you post, not vice versa! > Thanks, > > Larry Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> Uwe, please try the following patch:
>
> Index: bu3sch-wireless-dev/drivers/net/b44.c
> ===
> --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18
> 18:09:50.0 +0200 +++
> bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0 +0200
> @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> printk("%2.2x%c", dev->dev_addr[i],
> i == 5 ? '\n' : ':');
>
> +#if 0
> /* Initialize phy */
> spin_lock_irq(>lock);
> b44_chip_reset(bp);
> spin_unlock_irq(>lock);
> +#endif
>
> return 0;
Against what kernel please?
Just try to be a bit more eloquent, man!
Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 20:19 schrieben Sie: > On Sat, 26 May 2007 20:03:17 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > Ok, please take git and get my development tree and try with that: > > > > git clone http://bu3sch.de/git/wireless-dev.git > > > > It's based on 2.6.22-rc1 and it works fine for me. > > Uwe has a slow connection, and getting the whole git thing > set up would be quite a lump of effort. > > I prepared a diff of the above tree against 2.6.21-rc3. It is at > http://userweb.kernel.org/~akpm/git-mb.patch.gz OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew. Result is: No change: non functionable b44 device! Thank you for your help! Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 20:41 schrieben Sie: > On 5/26/07, Michael Buesch <[EMAIL PROTECTED]> wrote: > > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > > > Yes, sure! But the help text is very unlucky and humble, and it is not > > > clear enough in the sense of being distinctive enough, just clear and > > > comprehensive. > > > > Why don't you simply submit a patch to change the helptext then? > > Is that ok ? > > Discourage people from deselecting B44_PCI > > Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]> > > --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 > +++ kernel/drivers/net/Kconfig2007-05-26 20:38:15.0 +0200 > @@ -1449,7 +1449,7 @@ > help > Support for b44 PCI devices. > > - Say Y > + Unless you know what you are doing, say Y here. > > config FORCEDETH > tristate "nForce Ethernet support" No, That is NOT OK! That's nothing but a joke, and if it is a joke : ) it hits well in Mister Buesches direction. In so far it's well-done : ) : ) : ) To be honest: I expect at least TWO explained cases: A. The case in which the b44 module is a PCI module (onboard, additional PCI card etc.). B. At least one well described case in which the b44 module is a bus independent one. Apart from that, it is Michael's task to explain the what and why, not mine and not yours! It is him that wants his stuff being pulled into mainline, and in so far he very well can do the "dirty work" of documentation, explanation. But the issue is: He is not ready to DO that! Only if it fires back! Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 19:18 schrieben Sie: > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: > > Yes, sure! But the help text is very unlucky and humble, and it is not > > clear enough in the sense of being distinctive enough, just clear and > > comprehensive. > > Why don't you simply submit a patch to change the helptext then? > I'm not sure why you refuse to DO anything about the "mess", but > instead keep poking me that I am responsible somehow to fix it up > for you... I need exception examples for doing so. What are the exception examples? Apart from that you have don nothing except than guessing around. Now here comes the LAST proof that your code is buggy: A. It's not mm-implementation B. It's not user behaviour or fault C. It's not an ACPI issue BUT ONE AND ONLY: D. It's your code that is buggy, without any doubt! > > > > So I'm not sure why you keep bashing the kconfig implementation > > > here. It's common practice to have seperate config options for > > > bus-glues and it _automatically_ selects the right options for > > > you. > > > > Yes! But you need to EXPLAIN that "bus-glue" in the Kconfig help text in > > some two or three sentences. That shouldn't be that hard, should it? > > Ok, go for it. I need exception examples for doing so. What are the exception examples? OK, went Andrew's path: patched 2.6.22-rc3 with wireless tree: Result: The NIC driver b44 and ssb are loaded correctly, but refuse to work (no network communication possible). dmesg: Linux version 2.6.22-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Sat May 26 18:53:23 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffec000 (usable) BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 511MB LOWMEM available. Entering add_active_range(0, 0, 131052) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131052 early_node_map[1] active PFN ranges 0:0 -> 131052 On node 0 totalpages: 131052 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 991 pages used for memmap Normal zone: 125965 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP 000F5360, 0014 (r0 ASUS ) ACPI: RSDT 1FFEC000, 0030 (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: FACP 1FFEC0C0, 0074 (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: DSDT 1FFEC134, 2A43 (r1 ASUS P4PE 1000 MSFT 10B) ACPI: FACS 1000, 0040 ACPI: BOOT 1FFEC030, 0028 (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: APIC 1FFEC058, 005A (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists. Total pages: 130029 Kernel command line: root=/dev/hda1 ro vga=791 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1818.044 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 517056k/524208k available (1330k kernel code, 6608k reserved, 480k data, 136k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb8000 - 0xf000 ( 284 kB) vmalloc : 0xe080 - 0xfffb6000 ( 503 MB) lowmem : 0xc000 - 0xdffec000 ( 511 MB) .init : 0xc02c8000 - 0xc02ea000 ( 136 kB) .data : 0xc024cb0a - 0xc02c4c90 ( 480 kB) .text : 0xc010 - 0xc024cb0a (1330 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating dela
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 18:40 schrieben Sie: > On Saturday 26 May 2007 18:26:06 Uwe Bugla wrote: > > > I think we don't have IRQ assignment problems. Uwe simply disabled > > > b44-PCI support in his first bugreport (I guess). > > > > Yes! > > > > > So there was > > > no b44-PCI driver loaded. > > > > Well, not exactly: b44 plus ssb were in fact produced, but did not > > function, at least in that case, due to the misleading / superficial > > information in the Kconfig menu.. > > > > > Later on he said that it does magically work now... > > > > NO! > > > > Later on I said I did chose that b44-PCI driver, got the right > > dependencies, and there was no interrupt problem at all. So the driver > > got loaded as expected but simply did not work at all.. > > One small sidenote: > If you did _not_ play around with the b44/ssb kconfig options at all, > it would have selected the right options _automatically_ for you. > That means: > > cp ../old_kernel_without_ssb/.config . > make oldconfig > make > be done. > > You intentionaly disabled PCI device support for b44 and you > still wonder why it doesn't work on your PCI device? > I'm not sure how to make the helptext any clearer on the b44-PCI > option. A. Up to 2.6.21 there was only a b44 PCI driver. So you get used to it working with the same machine for years and compiling kernels for it. B. Now there are obviously some changes due to the "bus-glue". OK so far! But: The help text in both cases is exactly the same. And exactly that is the misleading point! The best way to put up a very clear distinction is to use some examples to explain the different cases. Now if you can offer me enough info on that I can try to do write a patch for that. So we got the Broadcom PCI b44 NIC driver (as card, as onboard device) and we got additionally what please as a new extension?? Just two or three examples would do it! Above that perhaps the dependencies could be a bit more precise: Wouldn't you get confused if you deselcted the PCI or Ethernet option, but still retaining the same b44 driver selected as module with the identical help text? Is that so hard to understand? > We have _lots_ of other drivers in the tree that work > EXACTLY the same way, regarding to kconfig. There are _lots_ > of drivers where there are seperate options for a "bus-glue". > b44-ssb is no different. And additionally it automatically > selects the right options for 99.9% of the users (you included). Yes, sure! But the help text is very unlucky and humble, and it is not clear enough in the sense of being distinctive enough, just clear and comprehensive. > > So I'm not sure why you keep bashing the kconfig implementation > here. It's common practice to have seperate config options for > bus-glues and it _automatically_ selects the right options for > you. Yes! But you need to EXPLAIN that "bus-glue" in the Kconfig help text in some two or three sentences. That shouldn't be that hard, should it? And that is exactly the basic function of a Kconfig help text: To explain kernel compilation choices to users! It is very very easy to simply ignore that fact and then, afterwards, call all people dumb who are not "omniscient" at all to see the differences through. Where should they know from if they are not identical with your personality? Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 18:21 schrieben Sie: > On Saturday 26 May 2007 18:13:09 Andrew Morton wrote: > > > I already tried your -mm kernel, but it crashes on my machine > > > for other reasons. (Yeah, I should look into them, too :P ) > > > > err, please do. Just the oops trace would be a start. > > Yes, I will look into it. I think it was related to my > onboard RTL networking chip. When trying to bring it down, > it oopses the machine. But I'm not sure what happens exactly, yet. > I'll take a look at it. > > > > Andrew, is it possible that the breakage was introduced in the > > > merge process somehow? Didn't the patch apply cleanly? Are there > > > other changes to b44 I should know about in your tree? > > > > Only git-wireless.net modifies b44.c but if we're having IRQ assignment > > problems then we'd need to look elsewhere. > > I think we don't have IRQ assignment problems. Uwe simply disabled > b44-PCI support in his first bugreport (I guess). Yes! > So there was > no b44-PCI driver loaded. Well, not exactly: b44 plus ssb were in fact produced, but did not function, at least in that case, due to the misleading / superficial information in the Kconfig menu.. > Later on he said that it does magically work now... NO! Later on I said I did chose that b44-PCI driver, got the right dependencies, and there was no interrupt problem at all. So the driver got loaded as expected but simply did not work at all.. Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 18:13 schrieben Sie: > On Sat, 26 May 2007 17:50:48 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > Andrew, > > > > I am going to ignore Uwe from now on. It's simply impossible > > to debug the problem the way he is responding. > > Well, I'm not the first person in the Linux community adding > > him to the killfile, ... . > > Well yes, there are some personality issues here ;) But the main thing is > to struggle on and fix this bug, wherever it lies. > > > I ask to try wireless-dev, as the driver works perfectly fine > > for me there, but he refuses to try it, too. So I'm stuck. > > I don't think he knows how to obtain it. > > Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current > wireless tree. That's a patch against 2.6.22-rc3. Could you please test > that? If that works then we know that the bug probably lies outside the > b44 driver (or it was subsequently fixed). Thank you, Andrew, just wait for a while. I am gonna try. > > > I already tried your -mm kernel, but it crashes on my machine > > for other reasons. (Yeah, I should look into them, too :P ) > > err, please do. Just the oops trace would be a start. > > > Andrew, is it possible that the breakage was introduced in the > > merge process somehow? Didn't the patch apply cleanly? Are there > > other changes to b44 I should know about in your tree? > > Only git-wireless.net modifies b44.c but if we're having IRQ assignment > problems then we'd need to look elsewhere. I guess you could diff > rc2-mm1's b44.c against the expected version. > > > If it is really impossible to debug this problem, I'd like to > > suggest you to drop the b44-ssb port completely. > > Well we don't know if that'll fix it. > > I believe that Uwe said that reverting the b44.c changes from rc2-mm1 fixes > things for him? Odd, but it still doesn't rule out acip/pci/platform > changes as being the cause. No, Andrew, not odd, but simply real! And Maximilian Engelhardt replied something similar on that : ) Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 17:50 schrieben Sie: > Andrew, > > I am going to ignore Uwe from now on. It's simply impossible > to debug the problem the way he is responding. > Well, I'm not the first person in the Linux community adding > him to the killfile, ... . > I ask to try wireless-dev, as the driver works perfectly fine > for me there, but he refuses to try it, too. So I'm stuck. A. Where can I get wireless-dev, please? B. Against what kernel can I apply it? C. How must this stuff be applied? Three clear questions, three clear answers please, if we want get forward. Apart from that I do not owe a wireless device, and i more and more get the impression that you simply do not want to rework your code. You rather search hungrily for excuses to point to some voluntary other side as soon as your code does not seem to work as expected and as soon as responsibilty issues are concerned. So what tester would enjoy such a stubborn behaviour? And additionally: Without getting paid for all the time effort? > I already tried your -mm kernel, but it crashes on my machine > for other reasons. (Yeah, I should look into them, too :P ) > > Andrew, is it possible that the breakage was introduced in the > merge process somehow? Didn't the patch apply cleanly? Are there > other changes to b44 I should know about in your tree? I think you can easily compare your wireless-dev code (where can I download it?) with the patch in the mm-tree. A simple diff will do I suppose. > > If it is really impossible to debug this problem, I'd like to > suggest you to drop the b44-ssb port completely. > I'm not going to destroy my nerves any further with guys like > Uwe, so I'll include the b44-ssb port in the OpenWRT tree > and be done with it. As I stated already, debugging is not impossible! In fact your responses didn't even mention real debugging as a choice. To debug the issue I need the debug command line parametres for both ssb and b44. I cannot guess them, as there is no documentation available, neither for b44 nor for ssb. So what are the debug parametres please? > Although I would be very sad about it, as my longterm goal was > to make a vanilla kernel run on the OpenWRT devices... . It is not my primary goal to leave you alone with this.. > > But maybe we can get another tester for -mm with similiar problems, > who is not bullshitting the whole time and is also going to > test wireless-dev to make sure it's not a merge bug. No, we need simply friendlier code developers without that immense arrogance behaviour that you show. That's it. > > > --- > > And Uwe: Remember, I am not payed for this. I do _all_ this > in my free time. > So sentences like: "So, the ball has been in your court > for two days now, and you simply keep on hesitating > to take action now." > are _completely_ displaced in this discussion. Yes. And I am doing this in my spare time too. And what I do not like is simply guessing around (ACPI bug, typo errors at DNS and nonsense like that etc.) plus this gesture going: "You are dumb, you are not understanding anything etc." Cheers and happy reflection Uwe P. S.: My door is open, although the whole issue starts to nerve me due to your behaviour. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 17:36 schrieben Sie: > On Saturday 26 May 2007 12:40:54 Uwe Bugla wrote: > > Yes! This sort of mistakes is completely impossible, as I use to work > > with aliases rather than IP adresses. The machine I tried to ping (i. e. > > my router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from > > Grateful Dead), and thus "ping jerry" returned the following: > > > > "destination host unreachable" > > > > Above that, I state for the second time now that I reverted your patches > > in 2.6.22-rc2-mm1 with the effect that everything worked perfectly! Maxi > > said something at least similar. So how many proofs do you need, Mister > > Buesch, to finally pick up patchworking now?? > > How about you stopping with your fucking aggressive wording?? If you stop repeating that you are not responsible for that buggy stuff then I will be friendlier. That's all. So calm down and provide me some parametres to debug. I will be cooperative and we're gonna fix it for sure, OK? > > > > Try it again, please. > > > > NO! > > > > > And please try with current wireless-dev tree. > > > > A. I do not know where to download that wireless-dev tree. > > B. I do not know how to implement it into mm or mainline > > C. I have given enough sophisticated proof that your stuff in mm-tree is > > highly incomplete / buggy. > > Ok, > > D. As you are not going to help me debugging, I am not going to fix. First of all, I need debugging parametres for both modules (b44 and ssb). Second, I need to know which log you need after using those debug parametres. This is the only chance to move forward, isn't it? > > > > And I simply do not get it why you suddenly get a good IRQ number, like > > > everybody else does, without fixing The Bug (tm). > > > > That consequence I already explained: > > But it's a pleasure for me to repeat it once more: > > > > When you are saying Y to "EISA, VLB, PCI and on board controllers" > > > > you simply do get not only completely different interrupts for the b4401 > > device, but you get also completely different module dependencies. > > That is EXPECTED and I already explained that. > It is a feature. Not a bug. Yes. But the features / extensions / different cases of b44 usage need to be explained in some small Kconfig text, making it easy for users to put the right selection for their specific NIC controller. But exactly this Kconfig leaves you in the dark. That's it what I critizise, nothing else. Just try to see through my eyes: Who would be happy with guessing around? Noone. Cheers Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 07:00 schrieben Sie: > On Friday 25 May 2007 21:40, Uwe Bugla wrote: > > Am Freitag, 25. Mai 2007 20:48 schrieben Sie: > > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote: > > > > Perhaps someone reading this could try to reproduce that problem on > > > > his machine. > > > > Now who of the readers owes a Broadcom 4401 NIC and can please try to > > > > test kernel 2.6.22-rc2-mm1? > > > > > > > > Those NICs have been used very very often as onboard controllers, > > > > especially on ASUS boards. > > > > > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2- > > > mm1 and both work fine with the BCM4401 in my laptop. > > > > > > Maxi > > > > Hello Maxi, > > > > That may be true for your Laptop, but it unfortunately isn't true for my > > ASUS mainboard onboard controller. > > > > Unfortunately I cannot confirm this: > > > > My broadcom 4401 driver is not part of a notebook, but instead part of an > > ASUS P4PE mainboard. > > > > At my second attempt I went the conventional path (i. e. ignoring the > > fact that > > "Broadcom 4400 ethernet support appears twice in section "Network device > > support": > > > > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it > > simply appears twice in kernel config! This is bug number 1. > > No it is NOT a bug. > It simply shows again that you don't know how b44, ssb or anything related > works. > > Would you _please_ take a look at the code, before calling features bugs. > And yes, this IS a feature. It is a feature to get b44 running on an > OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST > NOT depend on "EISA, VLB, PCI and on board controllers". Thanks for the descriptive lesson! But this explanation is displaced HERE. It should be part of the Kconfig text instead, as the b44 running on an OpenWRT embedded device simply does not show up in Kernel configuration of 2.6.21.2 and earlier kernels. In so far there is a bug that I would call superficial and incomplete explanation of b44 features in Kconfig! Just two or three explaining sentences at the appropriate place would do well instead of singing this aria again an again: "It simply shows again that you don't know how b44, ssb or anything related works." It's NOT MY task to be omnicient. Above that, the b44 modules have never been documented at all. So how can you expect me and others to know about the latest features of version 2? Very strange behaviour of yours ) : > "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on > board controllers". Thanks, now I know. But the dependencies chaos plus the PCI disfunctionality stays unfortunately! > > Everything is correct. > Bug number 1 is solved. NO! See above please and DO NOT IGNORE! > qed > > > This time I do get a "good" interrupt: IRQ 21 for the the device. > > > > BUT: > > > > Trying to ping another machine fails saying: > > > > "destination host unreachable" > > > > > > That means, Although the interrupt is fine now, the device is still not > > functionable. > > And it's completely impossible that you did a mistake when configuring > the device? Typo in the IP? Typo in the gateway or DNS entries? Yes! This sort of mistakes is completely impossible, as I use to work with aliases rather than IP adresses. The machine I tried to ping (i. e. my router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from Grateful Dead), and thus "ping jerry" returned the following: "destination host unreachable" Above that, I state for the second time now that I reverted your patches in 2.6.22-rc2-mm1 with the effect that everything worked perfectly! Maxi said something at least similar. So how many proofs do you need, Mister Buesch, to finally pick up patchworking now?? So, the ball has been in your court for two days now, and you simply keep on hesitating to take action now. Instead you are playing a nonsense "I-am-not-responsible-and-you-don't-know-Ping-Pong game" ignoring every hint, criticism that you are offered. REAL GREAT! > Try it again, please. NO! > And please try with current wireless-dev tree. A. I do not know where to download that wireless-dev tree. B. I do not know how to implement it into mm or mainline C. I have given enough sophisticated proof that your stuff in mm-tree is highly incomplete / buggy. > > And I simply do not get it why you suddenly get a good IRQ number, like > everybody else does, witho
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 07:00 schrieben Sie: On Friday 25 May 2007 21:40, Uwe Bugla wrote: Am Freitag, 25. Mai 2007 20:48 schrieben Sie: On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote: Perhaps someone reading this could try to reproduce that problem on his machine. Now who of the readers owes a Broadcom 4401 NIC and can please try to test kernel 2.6.22-rc2-mm1? Those NICs have been used very very often as onboard controllers, especially on ASUS boards. I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2- mm1 and both work fine with the BCM4401 in my laptop. Maxi Hello Maxi, That may be true for your Laptop, but it unfortunately isn't true for my ASUS mainboard onboard controller. Unfortunately I cannot confirm this: My broadcom 4401 driver is not part of a notebook, but instead part of an ASUS P4PE mainboard. At my second attempt I went the conventional path (i. e. ignoring the fact that Broadcom 4400 ethernet support appears twice in section Network device support: Whether you leave out EISA, VLB, PCI and on board controllers or not it simply appears twice in kernel config! This is bug number 1. No it is NOT a bug. It simply shows again that you don't know how b44, ssb or anything related works. Would you _please_ take a look at the code, before calling features bugs. And yes, this IS a feature. It is a feature to get b44 running on an OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST NOT depend on EISA, VLB, PCI and on board controllers. Thanks for the descriptive lesson! But this explanation is displaced HERE. It should be part of the Kconfig text instead, as the b44 running on an OpenWRT embedded device simply does not show up in Kernel configuration of 2.6.21.2 and earlier kernels. In so far there is a bug that I would call superficial and incomplete explanation of b44 features in Kconfig! Just two or three explaining sentences at the appropriate place would do well instead of singing this aria again an again: It simply shows again that you don't know how b44, ssb or anything related works. It's NOT MY task to be omnicient. Above that, the b44 modules have never been documented at all. So how can you expect me and others to know about the latest features of version 2? Very strange behaviour of yours ) : Broadcom 4400 PCI device support does depend on EISA, VLB, PCI and on board controllers. Thanks, now I know. But the dependencies chaos plus the PCI disfunctionality stays unfortunately! Everything is correct. Bug number 1 is solved. NO! See above please and DO NOT IGNORE! qed This time I do get a good interrupt: IRQ 21 for the the device. BUT: Trying to ping another machine fails saying: destination host unreachable That means, Although the interrupt is fine now, the device is still not functionable. And it's completely impossible that you did a mistake when configuring the device? Typo in the IP? Typo in the gateway or DNS entries? Yes! This sort of mistakes is completely impossible, as I use to work with aliases rather than IP adresses. The machine I tried to ping (i. e. my router) is called Jerry (as a reminiscence to Mr. Captan Trips from Grateful Dead), and thus ping jerry returned the following: destination host unreachable Above that, I state for the second time now that I reverted your patches in 2.6.22-rc2-mm1 with the effect that everything worked perfectly! Maxi said something at least similar. So how many proofs do you need, Mister Buesch, to finally pick up patchworking now?? So, the ball has been in your court for two days now, and you simply keep on hesitating to take action now. Instead you are playing a nonsense I-am-not-responsible-and-you-don't-know-Ping-Pong game ignoring every hint, criticism that you are offered. REAL GREAT! Try it again, please. NO! And please try with current wireless-dev tree. A. I do not know where to download that wireless-dev tree. B. I do not know how to implement it into mm or mainline C. I have given enough sophisticated proof that your stuff in mm-tree is highly incomplete / buggy. And I simply do not get it why you suddenly get a good IRQ number, like everybody else does, without fixing The Bug (tm). That consequence I already explained: But it's a pleasure for me to repeat it once more: When you are saying Y to EISA, VLB, PCI and on board controllers you simply do get not only completely different interrupts for the b4401 device, but you get also completely different module dependencies. If the module dependencies are correct the IRQ number is also correct, If the module dependencies are broken the IRQ number is also broken. It's as easy as that simply! In other words, UTMOST CLEAR: Runningh a PCI B4401 NIC: A. If you declare the b4401 device in Kconfig as a non PCI device (well, how should you know if there is neither
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 17:36 schrieben Sie: On Saturday 26 May 2007 12:40:54 Uwe Bugla wrote: Yes! This sort of mistakes is completely impossible, as I use to work with aliases rather than IP adresses. The machine I tried to ping (i. e. my router) is called Jerry (as a reminiscence to Mr. Captan Trips from Grateful Dead), and thus ping jerry returned the following: destination host unreachable Above that, I state for the second time now that I reverted your patches in 2.6.22-rc2-mm1 with the effect that everything worked perfectly! Maxi said something at least similar. So how many proofs do you need, Mister Buesch, to finally pick up patchworking now?? How about you stopping with your fucking aggressive wording?? If you stop repeating that you are not responsible for that buggy stuff then I will be friendlier. That's all. So calm down and provide me some parametres to debug. I will be cooperative and we're gonna fix it for sure, OK? Try it again, please. NO! And please try with current wireless-dev tree. A. I do not know where to download that wireless-dev tree. B. I do not know how to implement it into mm or mainline C. I have given enough sophisticated proof that your stuff in mm-tree is highly incomplete / buggy. Ok, D. As you are not going to help me debugging, I am not going to fix. First of all, I need debugging parametres for both modules (b44 and ssb). Second, I need to know which log you need after using those debug parametres. This is the only chance to move forward, isn't it? And I simply do not get it why you suddenly get a good IRQ number, like everybody else does, without fixing The Bug (tm). That consequence I already explained: But it's a pleasure for me to repeat it once more: When you are saying Y to EISA, VLB, PCI and on board controllers you simply do get not only completely different interrupts for the b4401 device, but you get also completely different module dependencies. That is EXPECTED and I already explained that. It is a feature. Not a bug. Yes. But the features / extensions / different cases of b44 usage need to be explained in some small Kconfig text, making it easy for users to put the right selection for their specific NIC controller. But exactly this Kconfig leaves you in the dark. That's it what I critizise, nothing else. Just try to see through my eyes: Who would be happy with guessing around? Noone. Cheers Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 17:50 schrieben Sie: Andrew, I am going to ignore Uwe from now on. It's simply impossible to debug the problem the way he is responding. Well, I'm not the first person in the Linux community adding him to the killfile, ... . I ask to try wireless-dev, as the driver works perfectly fine for me there, but he refuses to try it, too. So I'm stuck. A. Where can I get wireless-dev, please? B. Against what kernel can I apply it? C. How must this stuff be applied? Three clear questions, three clear answers please, if we want get forward. Apart from that I do not owe a wireless device, and i more and more get the impression that you simply do not want to rework your code. You rather search hungrily for excuses to point to some voluntary other side as soon as your code does not seem to work as expected and as soon as responsibilty issues are concerned. So what tester would enjoy such a stubborn behaviour? And additionally: Without getting paid for all the time effort? I already tried your -mm kernel, but it crashes on my machine for other reasons. (Yeah, I should look into them, too :P ) Andrew, is it possible that the breakage was introduced in the merge process somehow? Didn't the patch apply cleanly? Are there other changes to b44 I should know about in your tree? I think you can easily compare your wireless-dev code (where can I download it?) with the patch in the mm-tree. A simple diff will do I suppose. If it is really impossible to debug this problem, I'd like to suggest you to drop the b44-ssb port completely. I'm not going to destroy my nerves any further with guys like Uwe, so I'll include the b44-ssb port in the OpenWRT tree and be done with it. As I stated already, debugging is not impossible! In fact your responses didn't even mention real debugging as a choice. To debug the issue I need the debug command line parametres for both ssb and b44. I cannot guess them, as there is no documentation available, neither for b44 nor for ssb. So what are the debug parametres please? Although I would be very sad about it, as my longterm goal was to make a vanilla kernel run on the OpenWRT devices... . It is not my primary goal to leave you alone with this.. But maybe we can get another tester for -mm with similiar problems, who is not bullshitting the whole time and is also going to test wireless-dev to make sure it's not a merge bug. No, we need simply friendlier code developers without that immense arrogance behaviour that you show. That's it. --- And Uwe: Remember, I am not payed for this. I do _all_ this in my free time. So sentences like: So, the ball has been in your court for two days now, and you simply keep on hesitating to take action now. are _completely_ displaced in this discussion. Yes. And I am doing this in my spare time too. And what I do not like is simply guessing around (ACPI bug, typo errors at DNS and nonsense like that etc.) plus this gesture going: You are dumb, you are not understanding anything etc. Cheers and happy reflection Uwe P. S.: My door is open, although the whole issue starts to nerve me due to your behaviour. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 18:13 schrieben Sie: On Sat, 26 May 2007 17:50:48 +0200 Michael Buesch [EMAIL PROTECTED] wrote: Andrew, I am going to ignore Uwe from now on. It's simply impossible to debug the problem the way he is responding. Well, I'm not the first person in the Linux community adding him to the killfile, ... . Well yes, there are some personality issues here ;) But the main thing is to struggle on and fix this bug, wherever it lies. I ask to try wireless-dev, as the driver works perfectly fine for me there, but he refuses to try it, too. So I'm stuck. I don't think he knows how to obtain it. Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current wireless tree. That's a patch against 2.6.22-rc3. Could you please test that? If that works then we know that the bug probably lies outside the b44 driver (or it was subsequently fixed). Thank you, Andrew, just wait for a while. I am gonna try. I already tried your -mm kernel, but it crashes on my machine for other reasons. (Yeah, I should look into them, too :P ) err, please do. Just the oops trace would be a start. Andrew, is it possible that the breakage was introduced in the merge process somehow? Didn't the patch apply cleanly? Are there other changes to b44 I should know about in your tree? Only git-wireless.net modifies b44.c but if we're having IRQ assignment problems then we'd need to look elsewhere. I guess you could diff rc2-mm1's b44.c against the expected version. If it is really impossible to debug this problem, I'd like to suggest you to drop the b44-ssb port completely. Well we don't know if that'll fix it. I believe that Uwe said that reverting the b44.c changes from rc2-mm1 fixes things for him? Odd, but it still doesn't rule out acip/pci/platform changes as being the cause. No, Andrew, not odd, but simply real! And Maximilian Engelhardt replied something similar on that : ) Cheers Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 18:21 schrieben Sie: On Saturday 26 May 2007 18:13:09 Andrew Morton wrote: I already tried your -mm kernel, but it crashes on my machine for other reasons. (Yeah, I should look into them, too :P ) err, please do. Just the oops trace would be a start. Yes, I will look into it. I think it was related to my onboard RTL networking chip. When trying to bring it down, it oopses the machine. But I'm not sure what happens exactly, yet. I'll take a look at it. Andrew, is it possible that the breakage was introduced in the merge process somehow? Didn't the patch apply cleanly? Are there other changes to b44 I should know about in your tree? Only git-wireless.net modifies b44.c but if we're having IRQ assignment problems then we'd need to look elsewhere. I think we don't have IRQ assignment problems. Uwe simply disabled b44-PCI support in his first bugreport (I guess). Yes! So there was no b44-PCI driver loaded. Well, not exactly: b44 plus ssb were in fact produced, but did not function, at least in that case, due to the misleading / superficial information in the Kconfig menu.. Later on he said that it does magically work now... NO! Later on I said I did chose that b44-PCI driver, got the right dependencies, and there was no interrupt problem at all. So the driver got loaded as expected but simply did not work at all.. Cheers Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 18:40 schrieben Sie: On Saturday 26 May 2007 18:26:06 Uwe Bugla wrote: I think we don't have IRQ assignment problems. Uwe simply disabled b44-PCI support in his first bugreport (I guess). Yes! So there was no b44-PCI driver loaded. Well, not exactly: b44 plus ssb were in fact produced, but did not function, at least in that case, due to the misleading / superficial information in the Kconfig menu.. Later on he said that it does magically work now... NO! Later on I said I did chose that b44-PCI driver, got the right dependencies, and there was no interrupt problem at all. So the driver got loaded as expected but simply did not work at all.. One small sidenote: If you did _not_ play around with the b44/ssb kconfig options at all, it would have selected the right options _automatically_ for you. That means: cp ../old_kernel_without_ssb/.config . make oldconfig make be done. You intentionaly disabled PCI device support for b44 and you still wonder why it doesn't work on your PCI device? I'm not sure how to make the helptext any clearer on the b44-PCI option. A. Up to 2.6.21 there was only a b44 PCI driver. So you get used to it working with the same machine for years and compiling kernels for it. B. Now there are obviously some changes due to the bus-glue. OK so far! But: The help text in both cases is exactly the same. And exactly that is the misleading point! The best way to put up a very clear distinction is to use some examples to explain the different cases. Now if you can offer me enough info on that I can try to do write a patch for that. So we got the Broadcom PCI b44 NIC driver (as card, as onboard device) and we got additionally what please as a new extension?? Just two or three examples would do it! Above that perhaps the dependencies could be a bit more precise: Wouldn't you get confused if you deselcted the PCI or Ethernet option, but still retaining the same b44 driver selected as module with the identical help text? Is that so hard to understand? We have _lots_ of other drivers in the tree that work EXACTLY the same way, regarding to kconfig. There are _lots_ of drivers where there are seperate options for a bus-glue. b44-ssb is no different. And additionally it automatically selects the right options for 99.9% of the users (you included). Yes, sure! But the help text is very unlucky and humble, and it is not clear enough in the sense of being distinctive enough, just clear and comprehensive. So I'm not sure why you keep bashing the kconfig implementation here. It's common practice to have seperate config options for bus-glues and it _automatically_ selects the right options for you. Yes! But you need to EXPLAIN that bus-glue in the Kconfig help text in some two or three sentences. That shouldn't be that hard, should it? And that is exactly the basic function of a Kconfig help text: To explain kernel compilation choices to users! It is very very easy to simply ignore that fact and then, afterwards, call all people dumb who are not omniscient at all to see the differences through. Where should they know from if they are not identical with your personality? Cheers Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 19:18 schrieben Sie: On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: Yes, sure! But the help text is very unlucky and humble, and it is not clear enough in the sense of being distinctive enough, just clear and comprehensive. Why don't you simply submit a patch to change the helptext then? I'm not sure why you refuse to DO anything about the mess, but instead keep poking me that I am responsible somehow to fix it up for you... I need exception examples for doing so. What are the exception examples? Apart from that you have don nothing except than guessing around. Now here comes the LAST proof that your code is buggy: A. It's not mm-implementation B. It's not user behaviour or fault C. It's not an ACPI issue BUT ONE AND ONLY: D. It's your code that is buggy, without any doubt! So I'm not sure why you keep bashing the kconfig implementation here. It's common practice to have seperate config options for bus-glues and it _automatically_ selects the right options for you. Yes! But you need to EXPLAIN that bus-glue in the Kconfig help text in some two or three sentences. That shouldn't be that hard, should it? Ok, go for it. I need exception examples for doing so. What are the exception examples? OK, went Andrew's path: patched 2.6.22-rc3 with wireless tree: Result: The NIC driver b44 and ssb are loaded correctly, but refuse to work (no network communication possible). dmesg: Linux version 2.6.22-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Sat May 26 18:53:23 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1ffec000 (usable) BIOS-e820: 1ffec000 - 1ffef000 (ACPI data) BIOS-e820: 1ffef000 - 1000 (reserved) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 511MB LOWMEM available. Entering add_active_range(0, 0, 131052) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131052 early_node_map[1] active PFN ranges 0:0 - 131052 On node 0 totalpages: 131052 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 991 pages used for memmap Normal zone: 125965 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP 000F5360, 0014 (r0 ASUS ) ACPI: RSDT 1FFEC000, 0030 (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: FACP 1FFEC0C0, 0074 (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: DSDT 1FFEC134, 2A43 (r1 ASUS P4PE 1000 MSFT 10B) ACPI: FACS 1000, 0040 ACPI: BOOT 1FFEC030, 0028 (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: APIC 1FFEC058, 005A (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists. Total pages: 130029 Kernel command line: root=/dev/hda1 ro vga=791 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1818.044 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 517056k/524208k available (1330k kernel code, 6608k reserved, 480k data, 136k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb8000 - 0xf000 ( 284 kB) vmalloc : 0xe080 - 0xfffb6000 ( 503 MB) lowmem : 0xc000 - 0xdffec000 ( 511 MB) .init : 0xc02c8000 - 0xc02ea000 ( 136 kB) .data : 0xc024cb0a - 0xc02c4c90 ( 480 kB) .text : 0xc010 - 0xc024cb0a (1330 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3637.55 BogoMIPS (lpj=1818777) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febfbff
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 20:41 schrieben Sie: On 5/26/07, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote: Yes, sure! But the help text is very unlucky and humble, and it is not clear enough in the sense of being distinctive enough, just clear and comprehensive. Why don't you simply submit a patch to change the helptext then? Is that ok ? Discourage people from deselecting B44_PCI Signed-off-by: Benoit Boissinot [EMAIL PROTECTED] --- kernel.orig/drivers/net/Kconfig 2007-05-26 20:38:02.0 +0200 +++ kernel/drivers/net/Kconfig2007-05-26 20:38:15.0 +0200 @@ -1449,7 +1449,7 @@ help Support for b44 PCI devices. - Say Y + Unless you know what you are doing, say Y here. config FORCEDETH tristate nForce Ethernet support No, That is NOT OK! That's nothing but a joke, and if it is a joke : ) it hits well in Mister Buesches direction. In so far it's well-done : ) : ) : ) To be honest: I expect at least TWO explained cases: A. The case in which the b44 module is a PCI module (onboard, additional PCI card etc.). B. At least one well described case in which the b44 module is a bus independent one. Apart from that, it is Michael's task to explain the what and why, not mine and not yours! It is him that wants his stuff being pulled into mainline, and in so far he very well can do the dirty work of documentation, explanation. But the issue is: He is not ready to DO that! Only if it fires back! Cheers Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 20:19 schrieben Sie: On Sat, 26 May 2007 20:03:17 +0200 Michael Buesch [EMAIL PROTECTED] wrote: Ok, please take git and get my development tree and try with that: git clone http://bu3sch.de/git/wireless-dev.git It's based on 2.6.22-rc1 and it works fine for me. Uwe has a slow connection, and getting the whole git thing set up would be quite a lump of effort. I prepared a diff of the above tree against 2.6.21-rc3. It is at http://userweb.kernel.org/~akpm/git-mb.patch.gz OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew. Result is: No change: non functionable b44 device! Thank you for your help! Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:19 schrieben Sie: Uwe, please try the following patch: Index: bu3sch-wireless-dev/drivers/net/b44.c === --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18 18:09:50.0 +0200 +++ bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0 +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct printk(%2.2x%c, dev-dev_addr[i], i == 5 ? '\n' : ':'); +#if 0 /* Initialize phy */ spin_lock_irq(bp-lock); b44_chip_reset(bp); spin_unlock_irq(bp-lock); +#endif return 0; Against what kernel please? Just try to be a bit more eloquent, man! Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:57 schrieben Sie: Uwe Bugla wrote: OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew. Result is: No change: non functionable b44 device! Could you please send the following: 1. the output of lsmod from the non-functioning kernel Nonsense! As I stated already, both modules (i. e. b44 and ssb) are loaded correctly. So please read the thread before you post that, not vice versa! 2. the output of dmesg from the non-functioning kernel 3. your .config used to create your non-functioning kernel. They are already in the thread. So please leave me alone with those lazy hints! Read bfore you post, not vice versa! Thanks, Larry Cheers Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 21:49 schrieben Sie: On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote: Am Samstag, 26. Mai 2007 21:19 schrieben Sie: Uwe, please try the following patch: Index: bu3sch-wireless-dev/drivers/net/b44.c === --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18 18:09:50.0 +0200 +++ bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0 +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct printk(%2.2x%c, dev-dev_addr[i], i == 5 ? '\n' : ':'); +#if 0 /* Initialize phy */ spin_lock_irq(bp-lock); b44_chip_reset(bp); spin_unlock_irq(bp-lock); +#endif return 0; Against what kernel please? Just try to be a bit more eloquent, man! Against a kernel which does not work for you, of course. Sometimes I wonder... (no better not say that). YES! And I wonder TOO, definitely! Quand meme (now, if you do not speak french: Above all that), I applied your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get your dream being fulfilled! Result is: No change! Non-functionable b44-device at all! Hint: Although being a non-hacker or non-developer I do have stepped across some experienced developer people who at least added some code to make their modules function in the following way: modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6) In so far, if you continue to state that debugging is nothing but guessing around wildly you are definitely wrong, showing us all your missing code hacker experience. If you DO continue like this every step will be a torture not only for me but for the reading folks as well. But every human being is here to learn and develop: In so far I am very optimistic! Apart from the Kconfig chaos that seems to be subordinate in your personal rating scale, you at least could have added some functions like the above mentioned functions. The fact that you simply ignored to imply those functions and continue to call other people dumb shows exactly how small and humble you are. Apart from that: The message that you rooted to my place was no proof at all for any kind of disfunctionality or compatibility issue! In that message the lack of performance of the enclosed or old or complete b44 module (i. e. PCI-only module) was criticised, NOT the one ripped by you personally into two modules called b44 and ssb. In so far I would deeply appreciate you personally to stick to the facts in your personal lack of knowledge about the b44 driver instead of playing bad politics against other people like me and others. Hello my dear Andrew Morton, Could you please do me and the rest of the world two favours? A. Rip Michael Buesches code out of the mm-tree B. Give Michael Buesch a fair chance to revise his disfunctionable code outside the mm-tree and / or the vanilla mainline. Side note for the what and why: I like to help avoid dangers by testing the mm-tree. BUT: If real debugging conforms to nothing but guessing around wildly let me tell you that I do not appreciate to be part of that torture due to the lack of experience of some German spare time hacker. A: proven by facts not knowing or even wanting to know how to imply appropriate functionable debug parametres in his driver code B: non-cooperative as far as Kconfig help features are concerned (i. E. help to understand the issues for users C: calling all people simply dumb who do not know about his personal issues at all Thank you, Andrew Morton! You are real fine! Sincerely Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Samstag, 26. Mai 2007 23:52 schrieben Sie: On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote: Am Samstag, 26. Mai 2007 21:49 schrieben Sie: On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote: Am Samstag, 26. Mai 2007 21:19 schrieben Sie: Uwe, please try the following patch: Index: bu3sch-wireless-dev/drivers/net/b44.c === --- bu3sch-wireless-dev.orig/drivers/net/b44.c2007-05-18 18:09:50.0 +0200 +++ bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.0 +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct printk(%2.2x%c, dev-dev_addr[i], i == 5 ? '\n' : ':'); +#if 0 /* Initialize phy */ spin_lock_irq(bp-lock); b44_chip_reset(bp); spin_unlock_irq(bp-lock); +#endif return 0; Against what kernel please? Just try to be a bit more eloquent, man! Against a kernel which does not work for you, of course. Sometimes I wonder... (no better not say that). YES! And I wonder TOO, definitely! Quand meme (now, if you do not speak french: Above all that), I applied your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get your dream being fulfilled! Result is: No change! Non-functionable b44-device at all! Hint: Although being a non-hacker or non-developer I do have stepped across some experienced developer people who at least added some code to make their modules function in the following way: modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6) In so far, if you continue to state that debugging is nothing but guessing around wildly you are definitely wrong, showing us all your missing code hacker experience. If you DO continue like this every step will be a torture not only for me but for the reading folks as well. But every human being is here to learn and develop: In so far I am very optimistic! Apart from the Kconfig chaos that seems to be subordinate in your personal rating scale, you at least could have added some functions like the above mentioned functions. The fact that you simply ignored to imply those functions and continue to call other people dumb shows exactly how small and humble you are. Apart from that: The message that you rooted to my place was no proof at all for any kind of disfunctionality or compatibility issue! In that message the lack of performance of the enclosed or old or complete b44 module (i. e. PCI-only module) was criticised, NOT the one ripped by you personally into two modules called b44 and ssb. In so far I would deeply appreciate you personally to stick to the facts in your personal lack of knowledge about the b44 driver instead of playing bad politics against other people like me and others. Hello my dear Andrew Morton, Could you please do me and the rest of the world two favours? A. Rip Michael Buesches code out of the mm-tree B. Give Michael Buesch a fair chance to revise his disfunctionable code outside the mm-tree and / or the vanilla mainline. Side note for the what and why: I like to help avoid dangers by testing the mm-tree. BUT: If real debugging conforms to nothing but guessing around wildly let me tell you that I do not appreciate to be part of that torture due to the lack of experience of some German spare time hacker. A: proven by facts not knowing or even wanting to know how to imply appropriate functionable debug parametres in his driver code B: non-cooperative as far as Kconfig help features are concerned (i. E. help to understand the issues for users C: calling all people simply dumb who do not know about his personal issues at all Thank you, Andrew Morton! You are real fine! Everyone just needs to cool down. And you both (Uwe and Michael) just need to try debugging the problem. Abstracting the SSB code into a library is clearly the correct solution, rather than having the same code in two separate places. The whole _point_ of having code in various trees (wireless, mm, etc) is to find these bugs before the patches hit mainline. Even testing on 3 machines may not uncover subtle bugs (for example, different behavior on different silicon revisions, especially in reverse-engineered parts), it's only something Michael can test so far before other people have to pick it up and test it. And that's where you come in, Uwe. So both of you should actually just stop the name-calling, suck it up, and debug the problem. We're getting nothing done here. Dan Yeah, Danny! But if someone's simply ignoring to apply debug functions into his module code and thus reducing the essence of debugging to wild guessing around, transforming the whole testing situation into a torture
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 20:48 schrieben Sie: > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote: > > Perhaps someone reading this could try to reproduce that problem on his > > machine. > > Now who of the readers owes a Broadcom 4401 NIC and can please try to > > test kernel 2.6.22-rc2-mm1? > > > > Those NICs have been used very very often as onboard controllers, > > especially on ASUS boards. > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2- > mm1 and both work fine with the BCM4401 in my laptop. > > Maxi Hello Maxi, That may be true for your Laptop, but it unfortunately isn't true for my ASUS mainboard onboard controller. Unfortunately I cannot confirm this: My broadcom 4401 driver is not part of a notebook, but instead part of an ASUS P4PE mainboard. At my second attempt I went the conventional path (i. e. ignoring the fact that "Broadcom 4400 ethernet support appears twice in section "Network device support": Whether you leave out "EISA, VLB, PCI and on board controllers" or not it simply appears twice in kernel config! This is bug number 1. Conventional path means: EISA, VLB, PCI and on board controllers Y Broadcom 4400 ethernet support m Broadcom 4400 PCI device support Y This configuration binds: Sonics Silicon Backplane Support m Support for SSB on PCI-bus host SSB PCI core driver This time I do get a "good" interrupt: IRQ 21 for the the device. BUT: Trying to ping another machine fails saying: "destination host unreachable" That means, Although the interrupt is fine now, the device is still not functionable. This is bug number 2. Cheers Uwe P. S.: Michael, Andrew, if you need additional information to resolve that issue please tell / ask me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 18:56 schrieben Sie: > On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > I bet your bug is _not_ caused by ssb, but by some other breakage > > in another subsystem. Maybe ACPI or APIC is broken? Try to boot > > the machine without ACPI and/or APIC. > > It wouldn't be the first time. > > Uwe, please generate the `dmesg -s 100' output for 2.6.22-rc2 and for > 2.6.22-rc2-mm1, feed them through `diff -u' and see if you can spot any > interesting-looking differences in the PCI/ACPI/IRQ area. Send both the > files to me and I'll stick them on a server and then I'll see if we can > hunt down the perpetrator. > > Thanks. Hi everybody, unfortunately Andrew's path can be proven to be wrong: There is no bug in the ACPI area at all. I reverted the following modules in 2.6.22-rc2-mm1: --- linux-2.6.22-rc2/drivers/net/b44.c 2007-05-19 02:24:07.0 -0700 +++ devel/drivers/net/b44.c 2007-05-22 21:55:36.0 -0700 AND: --- linux-2.6.22-rc2/drivers/net/b44.h 2007-04-25 23:42:17.0 -0700 +++ devel/drivers/net/b44.h 2007-05-22 21:55:36.0 -0700 AND: --- linux-2.6.22-rc2/drivers/usb/host/ohci-hcd.c2007-05-19 02:24:07.0 -0700 +++ devel/drivers/usb/host/ohci-hcd.c 2007-05-22 21:55:36.0 -0700 AND: --- /dev/null 2007-05-07 19:14:32.301975000 -0700 +++ devel/drivers/usb/host/ohci-ssb.c 2007-05-22 21:55:36.0 -0700 RESULT: Broadcom 4401 is working purrfectly! YUP! Apart from that the kernel configuration menu of 2.6.22-rc2-mm1 is highly confusing: Kernel Config differences: In kernel 2.6.21.2 you are bound to go: EISA, VLB, PCI and onboard controllers Y Broadcom 4400 ethernet support m Whereas in Kernel 2.6.22-rc2-mm1 is completely confusing: 1. There is a menu called Sonics Silicon Backplane, which does not exist in 2.6.21.2. 2. In Section Network device support Y Ethernet (10 or 100Mbit) Y you got 2 confusing choices: Option A: EISA, VLB, PCI and onboard controllers Y Broadcom 4400 ethernet support m Broadcom 4400 PCI device support y This enables "Sonic Silicon Backplane support m" OR, and this is in fact confusing: Option B: Leave OUT (!!!) EISA, VLB, PCI and onboard controllers Y Simply: Broadcom 4400 ethernet support m This enables "Sonic Silicon Backplane support m" Option B is proved to be working with the patch against the b44.c module reverted in 2.6.22-rc2-mm1. If it is NOT reverted, Option B fails, but the confusion stays: You do not get the idea whether "Support for SSB on PCI bus host m" is necessary or not! And above that, THIS ONE: "Broadcom 4400 ethernet support m" should never appear when THIS one: "EISA, VLB, PCI and onboard controllers Y" is DESELECTED, should it?? And that's it exactly what I meant when I mentioned that the ATTACHMENT of ssb to b44 is highly buggy! I hope, Michael, that you believe that now. If you need lspci -v or / and dmesg to prove that I am right and you are wrong: Pleasure for me, just ask please! Cheers Uwe P. S.: In clear words: I higly suspect that simply the kernel config bindings are highly buggy and chaotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
Am Freitag, 25. Mai 2007 19:28 schrieben Sie: > On Fri, 25 May 2007 18:01:34 +0200 Takashi Iwai <[EMAIL PROTECTED]> wrote: > > At Thu, 24 May 2007 13:09:21 -0700, > > > > Andrew Morton wrote: > > > On Thu, 24 May 2007 22:00:52 +0200 > > > > > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > > > Hi everybody, > > > > > > > > with 2.6.22-rc2-mm1 I do get sound out of my machine using > > > > snd-intel8x0 module, BUT: > > > > > > > > At least parts of that Alsa sound architecture do seem to be broken: > > > > > > I assume you're referring to this stuff? > > > > > > > snd_seq_device: Unknown symbol snd_iprintf > > > > snd_seq_device: Unknown symbol snd_device_new > > > > snd_rawmidi: Unknown symbol snd_info_register > > > > snd_rawmidi: Unknown symbol snd_seq_device_new > > > > snd_rawmidi: Unknown symbol snd_info_free_entry > > > > > > Probably some silly missing dependency. Please send the .config, > > > thanks. > > > > The culprit appears more ealier. It implies the missing > > soundcore.ko (or its dependency). > > > > > snd: Unknown symbol unregister_sound_special > > > snd: Unknown symbol register_sound_special_device > > > snd: Unknown symbol sound_class > > > > Uwe, could you try to revert this patch? > > use-menuconfig-objects-ii-sound.patch > > I think that patch has rotted. Too many underlying changes and the > handling of HAS_IOMEM (at least) appears to have been broken (by my > fixups). > > I'll drop it. > > If/when Jan resends it, pleze consider it promptly and don't leave > me trying to maintain the thing while you guys are madly changing other > stuff underneath it? > > Thanks. Hi everybody, I had some trouble to find out which patch is meant by "use-menuconfig-objects-ii-sound.patch" Just could not identify it. So I reverted the following patches of 2.6.22-rc2-mm1: --- linux-2.6.22-rc2/sound/Kconfig 2007-05-19 02:24:08.0 -0700 +++ devel/sound/Kconfig 2007-05-22 21:03:24.0 -0700 AND: --- linux-2.6.22-rc2/sound/drivers/Kconfig 2007-04-25 23:42:23.0 -0700 +++ devel/sound/drivers/Kconfig 2007-05-22 21:03:24.0 -0700 Result: The Alsa architecture is performing excellently! Cheers Uwe So at least one of them should be ripeed out for being buggy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 16:52 schrieben Sie: > On Friday 25 May 2007 15:59:49 Uwe Bugla wrote: > > Well if you're so clever in software development then please provide an > > exception handling for the ssb module which is specifically NOT needed by > > my onboard controller, OK? > > Just provide compatibility to non-wireless NICs, i. e. to non-ssb > > devices. > > What are you talking about? First of all, what is an ssb device please? AFAICS it looks like an extension of b44.c as far as module selection is concerned in kernel configuration. What it's function / purpose? Does its function / purpose apply to every platform? > > > I think you cannot just bind ssb tightly to b44.c, can you? > > You have no clue about how the b44 hardware works, do you? Should I? My broadcom 4401 is broken, but only in that specific mm1-tree. It's not broken in 2.6.22-rc2 for instance. So that's your patch that breaks it. > > > In so far the way how ssb is attached is buggy and wrong, apart from the > > fact that my controller is broken, disfunctional. > > Please explain in detail how ssb is wrong. I do not state that ssb is wrong, but I state that the ATTACHMENT of ssb to b44.c is wrong. That's a big difference. In all earlier kernels that b44 device has been fine, and ssb has never been seen. > > > That's how I understand Andrew Morton's guideline: "Test your patches on > > three different machines before sending them in." > > In so far I do expect that you at least take the effort of testing your > > stuff with a PCI NIC or onboard NIC of the BCM4401 class of NICs before > > you send your stuff in. > > > > In so far you just cannot delegate the testing to other people before you > > are sending in that stuff. > > That's what Andrew tried to explain to you. > > I tested this code on _all_ of my machines. These include: > Big-Endian powerpc machine. > Little-Endian i386 machine. > OpenWRT router device (ssb is capable of booting this device, > with some additional code, which is in the OpenWRT tree). > > So, now I count the machines (not that this number matters AT ALL): > One, two, three. Oh, there we go. What a surprise... Nice for you, but on my machine it is broken, the broadcom 4401 onboard NIC controller is unusable. > > > I am convinced that your solution runs on your machine, but the solution > > that you provide looks very rude, doesn't it? > > No, explain why. > In fact, it's considered to be a very elegant solution by various > developers who actually have a clue about how the hardware works. > ssb scales from a small MIPS embedded device to real big machines. > > > > Please provide more information on the actual _issue_. > > > > Sure, no problem: > > > > 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev > > 01) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard > > Flags: bus master, fast devsel, latency 32, IRQ 17 > > Memory at f100 (32-bit, non-prefetchable) [size=8K] > > Capabilities: > > > > > In this whole mail you basically only state that: > > > > IRQ 255 looks very idiotic, doesn't it? > > > > > > Explain that in detail, please. Why do you think it's wrong? > > > > The "traditional" IRQ table provides TWO cascaded blocks of 8 interrupt > > numbers. > > Gives a spectrum from 0 to 15, doesn't it? > > > > The ACPI system enlarges that, and on at least my system the highest > > interrupt number is 21. Now if there were some more cards installed the > > maximum number would perhaps amount to 25. > > > > In so far an IRQ value of 255 looks a bit very very strange, doesn't it? > > On your architecture, perhaps. I don't know. > > > > Which IRQ number do you get with the old b44 driver? > > > > IRQ 17 > > Ok, now I show you the code which determines the IRQ number in ssb: > > sdev->irq = bus->host_pci->irq; > > That's simple, isn't it? > It simply copies the IRQ number from the original PCI device. > > I bet your bug is _not_ caused by ssb, but by some other breakage > in another subsystem. Maybe ACPI or APIC is broken? Try to boot > the machine without ACPI and/or APIC. But if APIC were broken all the other devices would not work too. But they DO work! Please correct me if I draw incorrect conclusions. Do you mean to build a kernel without any ACPI functions? > > > I just downloaded latest -mm to test it on my machine, but the machine > keeps freezing with that kernel. But I get IRQ 21 for the b44 device. Fine! Why do I get then a whole sum of correct interrupts while the only strange / f
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 15:12 schrieben Sie: > On Thursday 24 May 2007 22:06:59 Andrew Morton wrote: > > On Thu, 24 May 2007 21:56:16 +0200 > > > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > > Hi everybody, > > > > (added linux-wireless, others) > > > > > The patch against b44.c contained in 2.6.22-rc2-mm1 has two > > > consequences: > > > > > > 1. a tight binding to module ssb whose function or necessity I neither > > > see through nor do comprehend > > > > > > 2. a breakdown (disfunctionality) of my onboard NIC. > > > > > > lspci -v looks like this: > > > > > > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE > > > DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer > > > Inc. Unknown device 80b2 > > > Flags: bus master, fast devsel, latency 0 > > > Memory at f800 (32-bit, prefetchable) [size=64M] > > > Capabilities: [e4] Vendor Specific Information > > > Capabilities: [a0] AGP version 2.0 > > > > > > 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE > > > Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus > > > master, 66MHz, fast devsel, latency 64 > > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > > > I/O behind bridge: d000-dfff > > > Memory behind bridge: f200-f27f > > > Prefetchable memory behind bridge: f3f0-f7ff > > > > > > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM > > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 > > > [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > > Flags: bus master, medium devsel, latency 0, IRQ 17 > > > I/O ports at b800 [size=32] > > > > > > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM > > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 > > > [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > > Flags: bus master, medium devsel, latency 0, IRQ 20 > > > I/O ports at b400 [size=32] > > > > > > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM > > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 > > > [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > > Flags: bus master, medium devsel, latency 0, IRQ 16 > > > I/O ports at b000 [size=32] > > > > > > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) > > > USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK > > > Computer Inc. Unknown device 8089 > > > Flags: bus master, medium devsel, latency 0, IRQ 18 > > > Memory at f180 (32-bit, non-prefetchable) [size=1K] > > > Capabilities: [50] Power Management version 2 > > > Capabilities: [58] Debug port > > > > > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) > > > (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 > > > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 > > > Memory behind bridge: f100-f17f > > > Prefetchable memory behind bridge: f280-f3ef > > > > > > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC > > > Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 > > > > > > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller > > > (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer > > > Inc. Unknown device 8089 > > > Flags: bus master, medium devsel, latency 0, IRQ 16 > > > I/O ports at 01f0 [size=8] > > > I/O ports at 03f4 [size=1] > > > I/O ports at 0170 [size=8] > > > I/O ports at 0374 [size=1] > > > I/O ports at f000 [size=16] > > > Memory at 3000 (32-bit, non-prefetchable) [size=1K] > > > > > > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) > > > SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown > > > device 8089 > > > Flags: medium devsel, IRQ 19 > > > I/O ports at e800 [size=32] > > > > > > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM > > > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK > > > Computer Inc. Unknown device 80b0 > > > Flags: bus master, medium devsel, latency 0, IRQ 19 > >
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 15:12 schrieben Sie: On Thursday 24 May 2007 22:06:59 Andrew Morton wrote: On Thu, 24 May 2007 21:56:16 +0200 Uwe Bugla [EMAIL PROTECTED] wrote: Hi everybody, (added linux-wireless, others) The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences: 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend 2. a breakdown (disfunctionality) of my onboard NIC. lspci -v looks like this: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b2 Flags: bus master, fast devsel, latency 0 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f200-f27f Prefetchable memory behind bridge: f3f0-f7ff 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at b800 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at b400 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at b000 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 18 Memory at f180 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 Memory behind bridge: f100-f17f Prefetchable memory behind bridge: f280-f3ef 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at f000 [size=16] Memory at 3000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: medium devsel, IRQ 19 I/O ports at e800 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b0 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at a800 [size=256] I/O ports at a400 [size=64] Memory at f080 (32-bit, non-prefetchable) [size=512] Memory at f000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f400 (32-bit, prefetchable) [size=64M] I/O ports at d800 [size=256] Memory at f200 (32-bit, non-prefetchable) [size=16K] Expansion ROM at f3fe [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard Flags: bus master, fast devsel, latency 32, IRQ 255 Memory at f100 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 16:52 schrieben Sie: On Friday 25 May 2007 15:59:49 Uwe Bugla wrote: Well if you're so clever in software development then please provide an exception handling for the ssb module which is specifically NOT needed by my onboard controller, OK? Just provide compatibility to non-wireless NICs, i. e. to non-ssb devices. What are you talking about? First of all, what is an ssb device please? AFAICS it looks like an extension of b44.c as far as module selection is concerned in kernel configuration. What it's function / purpose? Does its function / purpose apply to every platform? I think you cannot just bind ssb tightly to b44.c, can you? You have no clue about how the b44 hardware works, do you? Should I? My broadcom 4401 is broken, but only in that specific mm1-tree. It's not broken in 2.6.22-rc2 for instance. So that's your patch that breaks it. In so far the way how ssb is attached is buggy and wrong, apart from the fact that my controller is broken, disfunctional. Please explain in detail how ssb is wrong. I do not state that ssb is wrong, but I state that the ATTACHMENT of ssb to b44.c is wrong. That's a big difference. In all earlier kernels that b44 device has been fine, and ssb has never been seen. That's how I understand Andrew Morton's guideline: Test your patches on three different machines before sending them in. In so far I do expect that you at least take the effort of testing your stuff with a PCI NIC or onboard NIC of the BCM4401 class of NICs before you send your stuff in. In so far you just cannot delegate the testing to other people before you are sending in that stuff. That's what Andrew tried to explain to you. I tested this code on _all_ of my machines. These include: Big-Endian powerpc machine. Little-Endian i386 machine. OpenWRT router device (ssb is capable of booting this device, with some additional code, which is in the OpenWRT tree). So, now I count the machines (not that this number matters AT ALL): One, two, three. Oh, there we go. What a surprise... Nice for you, but on my machine it is broken, the broadcom 4401 onboard NIC controller is unusable. I am convinced that your solution runs on your machine, but the solution that you provide looks very rude, doesn't it? No, explain why. In fact, it's considered to be a very elegant solution by various developers who actually have a clue about how the hardware works. ssb scales from a small MIPS embedded device to real big machines. Please provide more information on the actual _issue_. Sure, no problem: 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard Flags: bus master, fast devsel, latency 32, IRQ 17 Memory at f100 (32-bit, non-prefetchable) [size=8K] Capabilities: access denied In this whole mail you basically only state that: IRQ 255 looks very idiotic, doesn't it? Explain that in detail, please. Why do you think it's wrong? The traditional IRQ table provides TWO cascaded blocks of 8 interrupt numbers. Gives a spectrum from 0 to 15, doesn't it? The ACPI system enlarges that, and on at least my system the highest interrupt number is 21. Now if there were some more cards installed the maximum number would perhaps amount to 25. In so far an IRQ value of 255 looks a bit very very strange, doesn't it? On your architecture, perhaps. I don't know. Which IRQ number do you get with the old b44 driver? IRQ 17 Ok, now I show you the code which determines the IRQ number in ssb: sdev-irq = bus-host_pci-irq; That's simple, isn't it? It simply copies the IRQ number from the original PCI device. I bet your bug is _not_ caused by ssb, but by some other breakage in another subsystem. Maybe ACPI or APIC is broken? Try to boot the machine without ACPI and/or APIC. But if APIC were broken all the other devices would not work too. But they DO work! Please correct me if I draw incorrect conclusions. Do you mean to build a kernel without any ACPI functions? I just downloaded latest -mm to test it on my machine, but the machine keeps freezing with that kernel. But I get IRQ 21 for the b44 device. Fine! Why do I get then a whole sum of correct interrupts while the only strange / false one (255) is exactly the one offered to b44.c? And for what do I get that ssb module who's functionality I do not understand? If you need futher info please ask. But the possibility that the whole APIC is broken is rather small I think. To exclude that I would rather rip out any APIC changes in 2.6.22-rc2-mm1, if there are any (didn't take a look for that - only found out that the whole system works fine with the exception of parts of the alsa architecture and this broken b44.c module. Cheers Uwe Perhaps someone reading this could try to reproduce that problem on his
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 18:56 schrieben Sie: On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch [EMAIL PROTECTED] wrote: I bet your bug is _not_ caused by ssb, but by some other breakage in another subsystem. Maybe ACPI or APIC is broken? Try to boot the machine without ACPI and/or APIC. It wouldn't be the first time. Uwe, please generate the `dmesg -s 100' output for 2.6.22-rc2 and for 2.6.22-rc2-mm1, feed them through `diff -u' and see if you can spot any interesting-looking differences in the PCI/ACPI/IRQ area. Send both the files to me and I'll stick them on a server and then I'll see if we can hunt down the perpetrator. Thanks. Hi everybody, unfortunately Andrew's path can be proven to be wrong: There is no bug in the ACPI area at all. I reverted the following modules in 2.6.22-rc2-mm1: --- linux-2.6.22-rc2/drivers/net/b44.c 2007-05-19 02:24:07.0 -0700 +++ devel/drivers/net/b44.c 2007-05-22 21:55:36.0 -0700 AND: --- linux-2.6.22-rc2/drivers/net/b44.h 2007-04-25 23:42:17.0 -0700 +++ devel/drivers/net/b44.h 2007-05-22 21:55:36.0 -0700 AND: --- linux-2.6.22-rc2/drivers/usb/host/ohci-hcd.c2007-05-19 02:24:07.0 -0700 +++ devel/drivers/usb/host/ohci-hcd.c 2007-05-22 21:55:36.0 -0700 AND: --- /dev/null 2007-05-07 19:14:32.301975000 -0700 +++ devel/drivers/usb/host/ohci-ssb.c 2007-05-22 21:55:36.0 -0700 RESULT: Broadcom 4401 is working purrfectly! YUP! Apart from that the kernel configuration menu of 2.6.22-rc2-mm1 is highly confusing: Kernel Config differences: In kernel 2.6.21.2 you are bound to go: EISA, VLB, PCI and onboard controllers Y Broadcom 4400 ethernet support m Whereas in Kernel 2.6.22-rc2-mm1 is completely confusing: 1. There is a menu called Sonics Silicon Backplane, which does not exist in 2.6.21.2. 2. In Section Network device support Y Ethernet (10 or 100Mbit) Y you got 2 confusing choices: Option A: EISA, VLB, PCI and onboard controllers Y Broadcom 4400 ethernet support m Broadcom 4400 PCI device support y This enables Sonic Silicon Backplane support m OR, and this is in fact confusing: Option B: Leave OUT (!!!) EISA, VLB, PCI and onboard controllers Y Simply: Broadcom 4400 ethernet support m This enables Sonic Silicon Backplane support m Option B is proved to be working with the patch against the b44.c module reverted in 2.6.22-rc2-mm1. If it is NOT reverted, Option B fails, but the confusion stays: You do not get the idea whether Support for SSB on PCI bus host m is necessary or not! And above that, THIS ONE: Broadcom 4400 ethernet support m should never appear when THIS one: EISA, VLB, PCI and onboard controllers Y is DESELECTED, should it?? And that's it exactly what I meant when I mentioned that the ATTACHMENT of ssb to b44 is highly buggy! I hope, Michael, that you believe that now. If you need lspci -v or / and dmesg to prove that I am right and you are wrong: Pleasure for me, just ask please! Cheers Uwe P. S.: In clear words: I higly suspect that simply the kernel config bindings are highly buggy and chaotic. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
Am Freitag, 25. Mai 2007 19:28 schrieben Sie: On Fri, 25 May 2007 18:01:34 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: At Thu, 24 May 2007 13:09:21 -0700, Andrew Morton wrote: On Thu, 24 May 2007 22:00:52 +0200 Uwe Bugla [EMAIL PROTECTED] wrote: Hi everybody, with 2.6.22-rc2-mm1 I do get sound out of my machine using snd-intel8x0 module, BUT: At least parts of that Alsa sound architecture do seem to be broken: I assume you're referring to this stuff? snd_seq_device: Unknown symbol snd_iprintf snd_seq_device: Unknown symbol snd_device_new snd_rawmidi: Unknown symbol snd_info_register snd_rawmidi: Unknown symbol snd_seq_device_new snd_rawmidi: Unknown symbol snd_info_free_entry Probably some silly missing dependency. Please send the .config, thanks. The culprit appears more ealier. It implies the missing soundcore.ko (or its dependency). snd: Unknown symbol unregister_sound_special snd: Unknown symbol register_sound_special_device snd: Unknown symbol sound_class Uwe, could you try to revert this patch? use-menuconfig-objects-ii-sound.patch I think that patch has rotted. Too many underlying changes and the handling of HAS_IOMEM (at least) appears to have been broken (by my fixups). I'll drop it. If/when Jan resends it, pleze consider it promptly and don't leave me trying to maintain the thing while you guys are madly changing other stuff underneath it? Thanks. Hi everybody, I had some trouble to find out which patch is meant by use-menuconfig-objects-ii-sound.patch Just could not identify it. So I reverted the following patches of 2.6.22-rc2-mm1: --- linux-2.6.22-rc2/sound/Kconfig 2007-05-19 02:24:08.0 -0700 +++ devel/sound/Kconfig 2007-05-22 21:03:24.0 -0700 AND: --- linux-2.6.22-rc2/sound/drivers/Kconfig 2007-04-25 23:42:23.0 -0700 +++ devel/sound/drivers/Kconfig 2007-05-22 21:03:24.0 -0700 Result: The Alsa architecture is performing excellently! Cheers Uwe So at least one of them should be ripeed out for being buggy. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Freitag, 25. Mai 2007 20:48 schrieben Sie: On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote: Perhaps someone reading this could try to reproduce that problem on his machine. Now who of the readers owes a Broadcom 4401 NIC and can please try to test kernel 2.6.22-rc2-mm1? Those NICs have been used very very often as onboard controllers, especially on ASUS boards. I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2- mm1 and both work fine with the BCM4401 in my laptop. Maxi Hello Maxi, That may be true for your Laptop, but it unfortunately isn't true for my ASUS mainboard onboard controller. Unfortunately I cannot confirm this: My broadcom 4401 driver is not part of a notebook, but instead part of an ASUS P4PE mainboard. At my second attempt I went the conventional path (i. e. ignoring the fact that Broadcom 4400 ethernet support appears twice in section Network device support: Whether you leave out EISA, VLB, PCI and on board controllers or not it simply appears twice in kernel config! This is bug number 1. Conventional path means: EISA, VLB, PCI and on board controllers Y Broadcom 4400 ethernet support m Broadcom 4400 PCI device support Y This configuration binds: Sonics Silicon Backplane Support m Support for SSB on PCI-bus host SSB PCI core driver This time I do get a good interrupt: IRQ 21 for the the device. BUT: Trying to ping another machine fails saying: destination host unreachable That means, Although the interrupt is fine now, the device is still not functionable. This is bug number 2. Cheers Uwe P. S.: Michael, Andrew, if you need additional information to resolve that issue please tell / ask me. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Donnerstag, 24. Mai 2007 22:06 schrieben Sie: > On Thu, 24 May 2007 21:56:16 +0200 > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > Hi everybody, > > (added linux-wireless, others) > > > The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences: > > > > 1. a tight binding to module ssb whose function or necessity I neither > > see through nor do comprehend > > > > 2. a breakdown (disfunctionality) of my onboard NIC. > > > > lspci -v looks like this: > > > > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM > > Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer Inc. > > Unknown device 80b2 > > Flags: bus master, fast devsel, latency 0 > > Memory at f800 (32-bit, prefetchable) [size=64M] > > Capabilities: [e4] Vendor Specific Information > > Capabilities: [a0] AGP version 2.0 > > > > 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE > > Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus > > master, 66MHz, fast devsel, latency 64 > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > > I/O behind bridge: d000-dfff > > Memory behind bridge: f200-f27f > > Prefetchable memory behind bridge: f3f0-f7ff > > > > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > Flags: bus master, medium devsel, latency 0, IRQ 17 > > I/O ports at b800 [size=32] > > > > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > Flags: bus master, medium devsel, latency 0, IRQ 20 > > I/O ports at b400 [size=32] > > > > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089 > > Flags: bus master, medium devsel, latency 0, IRQ 16 > > I/O ports at b000 [size=32] > > > > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > > EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer > > Inc. Unknown device 8089 > > Flags: bus master, medium devsel, latency 0, IRQ 18 > > Memory at f180 (32-bit, non-prefetchable) [size=1K] > > Capabilities: [50] Power Management version 2 > > Capabilities: [58] Debug port > > > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if > > 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 > > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 > > Memory behind bridge: f100-f17f > > Prefetchable memory behind bridge: f280-f3ef > > > > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC > > Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 > > > > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller > > (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. > > Unknown device 8089 > > Flags: bus master, medium devsel, latency 0, IRQ 16 > > I/O ports at 01f0 [size=8] > > I/O ports at 03f4 [size=1] > > I/O ports at 0170 [size=8] > > I/O ports at 0374 [size=1] > > I/O ports at f000 [size=16] > > Memory at 3000 (32-bit, non-prefetchable) [size=1K] > > > > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) > > SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device > > 8089 > > Flags: medium devsel, IRQ 19 > > I/O ports at e800 [size=32] > > > > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM > > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK > > Computer Inc. Unknown device 80b0 > > Flags: bus master, medium devsel, latency 0, IRQ 19 > > I/O ports at a800 [size=256] > > I/O ports at a400 [size=64] > > Memory at f080 (32-bit, non-prefetchable) [size=512] > > Memory at f000 (32-bit, non-prefetchable) [size=256] > > Capabilities: [50] Power Management version 2 > > > > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO > > AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fu
Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
Am Donnerstag, 24. Mai 2007 22:09 schrieben Sie: > On Thu, 24 May 2007 22:00:52 +0200 > > "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > Hi everybody, > > > > with 2.6.22-rc2-mm1 I do get sound out of my machine using snd-intel8x0 > > module, BUT: > > > > At least parts of that Alsa sound architecture do seem to be broken: > > I assume you're referring to this stuff? > > > snd_seq_device: Unknown symbol snd_iprintf > > snd_seq_device: Unknown symbol snd_device_new > > snd_rawmidi: Unknown symbol snd_info_register > > snd_rawmidi: Unknown symbol snd_seq_device_new > > snd_rawmidi: Unknown symbol snd_info_free_entry > > Probably some silly missing dependency. Please send the .config, thanks. Hi Andrew, now here is the .config as requested. At least I, from my personal comprehensive layer, do not see anything abnormal in it. But please evaluate yourself! # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc2-mm1 # Thu May 24 18:59:09 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # CONFIG_BLOCK is not set # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # 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_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m CONFIG_X86_MCE_P4THERMAL=y # CONFIG_VM86 is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_
BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
Hi everybody, with 2.6.22-rc2-mm1 I do get sound out of my machine using snd-intel8x0 module, BUT: At least parts of that Alsa sound architecture do seem to be broken: dmesg looks like this: 31 MSFT 31313031) ACPI: APIC 1FFEC058, 005A (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130029 Kernel command line: root=/dev/hda1 ro vga=791 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1818.042 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 517004k/524208k available (1366k kernel code, 6660k reserved, 492k data, 140k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb8000 - 0xf000 ( 284 kB) vmalloc : 0xe080 - 0xfffb6000 ( 503 MB) lowmem : 0xc000 - 0xdffec000 ( 511 MB) .init : 0xc02d4000 - 0xc02f7000 ( 140 kB) .data : 0xc0255b76 - 0xc02d0d30 ( 492 kB) .text : 0xc010 - 0xc0255b76 (1366 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3637.50 BogoMIPS (lpj=1818752) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febfbff CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: 3febfbff b080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Compat vDSO mapped to e000. CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 04 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf1e60, last bus=2 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) * The chipset may have PM-Timer Bug. Due to workarounds for a bug, * this clock source is slow. If you are sure your timer does not have * this bug, please use "acpi_pm_good" to disable the workaround PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region ec00-ec3f claimed by ICH4 GPIO PCI: Enabled i801 SMBus device PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT] 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) *0, disabled. 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 Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 17 devices ACPI: ACPI bus type pnp unregistered PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Time: tsc clocksource has been installed. pnp: 00:00: iomem range 0x0-0x9 could not be reserved pnp: 00:00: iomem range 0xf-0xf could not be reserved pnp: 00:00: iomem range 0x10-0x1fff could not be reserved pnp: 00:00: iomem range 0xfec0-0xfec000ff could not be reserved pnp: 00:02: ioport range 0xe400-0xe47f has been reserved pnp: 00:02: ioport range 0xe800-0xe81f has been reserved pnp: 00:02: ioport range 0xec00-0xec3f has been reserved pnp: 00:02: ioport range 0x4d6-0x4d6 has been
BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Hi everybody, The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences: 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend 2. a breakdown (disfunctionality) of my onboard NIC. lspci -v looks like this: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b2 Flags: bus master, fast devsel, latency 0 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f200-f27f Prefetchable memory behind bridge: f3f0-f7ff 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at b800 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at b400 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at b000 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 18 Memory at f180 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 Memory behind bridge: f100-f17f Prefetchable memory behind bridge: f280-f3ef 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at f000 [size=16] Memory at 3000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: medium devsel, IRQ 19 I/O ports at e800 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b0 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at a800 [size=256] I/O ports at a400 [size=64] Memory at f080 (32-bit, non-prefetchable) [size=512] Memory at f000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f400 (32-bit, prefetchable) [size=64M] I/O ports at d800 [size=256] Memory at f200 (32-bit, non-prefetchable) [size=16K] Expansion ROM at f3fe [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard Flags: bus master, fast devsel, latency 32, IRQ 255 Memory at f100 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities: [40] Power Management version 2 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Hi everybody, The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences: 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend 2. a breakdown (disfunctionality) of my onboard NIC. lspci -v looks like this: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b2 Flags: bus master, fast devsel, latency 0 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f200-f27f Prefetchable memory behind bridge: f3f0-f7ff 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at b800 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at b400 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at b000 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 18 Memory at f180 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 Memory behind bridge: f100-f17f Prefetchable memory behind bridge: f280-f3ef 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at f000 [size=16] Memory at 3000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: medium devsel, IRQ 19 I/O ports at e800 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b0 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at a800 [size=256] I/O ports at a400 [size=64] Memory at f080 (32-bit, non-prefetchable) [size=512] Memory at f000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f400 (32-bit, prefetchable) [size=64M] I/O ports at d800 [size=256] Memory at f200 (32-bit, non-prefetchable) [size=16K] Expansion ROM at f3fe [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard Flags: bus master, fast devsel, latency 32, IRQ 255 Memory at f100 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities: [40] Power Management version 2 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
Hi everybody, with 2.6.22-rc2-mm1 I do get sound out of my machine using snd-intel8x0 module, BUT: At least parts of that Alsa sound architecture do seem to be broken: dmesg looks like this: 31 MSFT 31313031) ACPI: APIC 1FFEC058, 005A (r1 ASUS P4PE 42302E31 MSFT 31313031) ACPI: PM-Timer IO Port: 0xe408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:2 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130029 Kernel command line: root=/dev/hda1 ro vga=791 mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1818.042 MHz processor. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 517004k/524208k available (1366k kernel code, 6660k reserved, 492k data, 140k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb8000 - 0xf000 ( 284 kB) vmalloc : 0xe080 - 0xfffb6000 ( 503 MB) lowmem : 0xc000 - 0xdffec000 ( 511 MB) .init : 0xc02d4000 - 0xc02f7000 ( 140 kB) .data : 0xc0255b76 - 0xc02d0d30 ( 492 kB) .text : 0xc010 - 0xc0255b76 (1366 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3637.50 BogoMIPS (lpj=1818752) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febfbff CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: 3febfbff b080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled Compat vDSO mapped to e000. CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 04 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf1e60, last bus=2 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) * The chipset may have PM-Timer Bug. Due to workarounds for a bug, * this clock source is slow. If you are sure your timer does not have * this bug, please use acpi_pm_good to disable the workaround PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region ec00-ec3f claimed by ICH4 GPIO PCI: Enabled i801 SMBus device PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT] 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) *0, disabled. 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 Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 17 devices ACPI: ACPI bus type pnp unregistered PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report Time: tsc clocksource has been installed. pnp: 00:00: iomem range 0x0-0x9 could not be reserved pnp: 00:00: iomem range 0xf-0xf could not be reserved pnp: 00:00: iomem range 0x10-0x1fff could not be reserved pnp: 00:00: iomem range 0xfec0-0xfec000ff could not be reserved pnp: 00:02: ioport range 0xe400-0xe47f has been reserved pnp: 00:02: ioport range 0xe800-0xe81f has been reserved pnp: 00:02: ioport range 0xec00-0xec3f has been reserved pnp: 00:02: ioport range 0x4d6-0x4d6 has been reserved
Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken
Am Donnerstag, 24. Mai 2007 22:09 schrieben Sie: On Thu, 24 May 2007 22:00:52 +0200 Uwe Bugla [EMAIL PROTECTED] wrote: Hi everybody, with 2.6.22-rc2-mm1 I do get sound out of my machine using snd-intel8x0 module, BUT: At least parts of that Alsa sound architecture do seem to be broken: I assume you're referring to this stuff? snd_seq_device: Unknown symbol snd_iprintf snd_seq_device: Unknown symbol snd_device_new snd_rawmidi: Unknown symbol snd_info_register snd_rawmidi: Unknown symbol snd_seq_device_new snd_rawmidi: Unknown symbol snd_info_free_entry Probably some silly missing dependency. Please send the .config, thanks. Hi Andrew, now here is the .config as requested. At least I, from my personal comprehensive layer, do not see anything abnormal in it. But please evaluate yourself! # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc2-mm1 # Thu May 24 18:59:09 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # CONFIG_BLOCK is not set # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # 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_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m CONFIG_X86_MCE_P4THERMAL=y # CONFIG_VM86 is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set
Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
Am Donnerstag, 24. Mai 2007 22:06 schrieben Sie: On Thu, 24 May 2007 21:56:16 +0200 Uwe Bugla [EMAIL PROTECTED] wrote: Hi everybody, (added linux-wireless, others) The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences: 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend 2. a breakdown (disfunctionality) of my onboard NIC. lspci -v looks like this: 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b2 Flags: bus master, fast devsel, latency 0 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f200-f27f Prefetchable memory behind bridge: f3f0-f7ff 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at b800 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at b400 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at b000 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 18 Memory at f180 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 Memory behind bridge: f100-f17f Prefetchable memory behind bridge: f280-f3ef 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at f000 [size=16] Memory at 3000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 8089 Flags: medium devsel, IRQ 19 I/O ports at e800 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 80b0 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at a800 [size=256] I/O ports at a400 [size=64] Memory at f080 (32-bit, non-prefetchable) [size=512] Memory at f000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17 Memory at f400 (32-bit, prefetchable) [size=64M] I/O ports at d800 [size=256] Memory at f200 (32-bit, non-prefetchable) [size=16K] Expansion ROM at f3fe [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard Flags: bus master, fast devsel, latency 32, IRQ 255 Memory at f100 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities: [40] Power Management version 2 02:0b.0 Multimedia video controller
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Dienstag, 22. Mai 2007 22:18 schrieben Sie: > On May 20 2007 07:28, Al Viro wrote: > >On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: > >> Ken? Ball's in your court. As the patch isn't providing a killer > >> feature for 2.6.22, I'd suggest just reverting it for now until the > >> issues are ironed out. > > > >Hold it. The real question here is which logics do we want there. > >IOW, and how many device nodes do we want to appear and _when_ do > >we want them to appear? > > "min_loop" (max_loop?) nodes should appear (but without a backing > gendisk), and when they are opened, they should get their gendisk > allocated and assigned. > > > > Jan Jan, Please stick to the latest revised patch residing in Andrew's mm-tree now. All that I wanted was a possibility to mount up to eight 8 iso images to be mounted parallely at boot time using udev and AVOID fuzzing around with additional nodes in /dev/loop. This desire isn't nonsense at all: For instance, if you run Debian "Lenny" testing, you need to mount 4 DVD iso images parallely at boot time (at least I do need that) if you do not want to waste time with opening and closing your DVD device at all. Then there may be other desires: a. For instance mounting Christian Marillat's unofficial Debian iso image at boot time (multimedia stuff). b. For instance to mount and run all sampled libraries for helping the wine package to be as compatible as possible (i. e. winetools by Joachim von Thadden) and so on. That means: At least for my personal desire, Ken Chen's latest patch was OK so far. Now, if there is a specific need for mounting up to 256 iso images including whatever technical basis or userspace tools requiries or changings of whatever kind then at least I do not care about the what and why at all. But the facts for now at least go like this: 1. Ken Chen's latest patch, criticised and enhanced by Andrew Morton, acked by Al Viro, is now part of the latest mm-tree. 2. The three patches leading to the disaster of breaking userspace are not yet ripped out of Linus's 2.6.22-rc2-tree. In so far I would deeply appreciate Linus Torvalds to rip put the mentioned patches mentioned, just to avoid future troubles. Yours sincerely Uwe P. S.: 1. The first approach, a common work by Ken Chen and Al Viro, was an approach promising up to 256 iso images to be mounted dynamically on user's demand while really offering only one iso image to be mounted and, after the desire to mount some more at boot time, stop working. I would evaluate that approach as stuff for cabaret laughter, jokin', or simply a terrible bug. 2. I do not like / appreciate discussions on items that seem to be far away from actual user's needs, without being proven by examples of real necessity. Otherwise expressed: Who really needs actually to mount up to 256 iso images using the loop device? I am ready to learn.. :) 3. I have seen this feature of "virtual DVD devices" under Windoze XP, established for whatever nonsense reason. Question: Who actually needs to mount parallely for instance up to 200 video DVDs wasting Ram like hell? I would call that a kind of fetish, i. e. I do not see the deeper sense of it! The base line for linux as an operating system is: "Small and effective is Beautiful", isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with 2.6.21.1 on an AMD K7 machine
Am Dienstag, 22. Mai 2007 13:18 schrieben Sie:
> Am Dienstag, 22. Mai 2007 00:54 schrieben Sie:
> > On Tue, 22 May 2007 00:28:57 +0200
> >
> > "Uwe Bugla" <[EMAIL PROTECTED]> wrote:
> > > kernel 2.6.21.1 makes my machine Oops about 20 seconds after KDE 3,5 is
> > > brought up showing its graphical login (kdm):
> >
> > We're completely blind unless we can see that oops info.
>
> Yes.
>
> And I am completely blind if I even once rely on some v4l "maintainer" who:
>
> a. has absolutely ZERO knowledge about DVB issues
> b. is not ready to share power and competence with a second or a third
> maintainer
> c. smashes down democratic votes (there have been 4 traditional highly
> experienced DVB maintainers voting for one person to resolve that issue -
> one of them was the "old rock" Ralph Metzler)
> d. reviews code that he absolutely has no idea about and signs it off
> e. gives stupid replies on specific questions due to his proven
> incompetence
>
> Would you call this man helpful and honest? My answer you can easily guess!
>
> > If it reached
> > /var/log/messages then please send it.
> >
> > If it didn't please set up netconsole
> > (Documentation/networking/netconsole.txt)
> >
> > If for some reason that isn't possible then you couldry switching to
> > the vga concole (alt-ctl-F1) before the ooops and see if the output
> > is visible on the VGA screen. If it is there, a digital photo will suit
> > (you can email it to me and I can stick it on a server somewhere if
> > you like). The last option is to write the oops info down with a
> > pencil and type it in again, but that's painful (all the hex addresses
> > in the stack backtrace can be omitted)
> >
> > Thanks.
>
> OK, back to the AMD K7 oops issue now:
>
> I in fact never could believe that a simple buggy NIC driver could ever
> hang up a whole machine!
>
> So, if someone could be kind enough to explain to me in how far that can
> happen I'd be very thankful.
>
> The solution for the 2.6.21.1 oops issue is the following patch, who needs
> to flow into vanilla mainline of 2.6.21.x as quick as possible:
>
> --- a/drivers/net/sis900.c
> +++ b/drivers/net/sis900.c
> @@ -1754,6 +1754,7 @@ static int sis900_rx(struct net_device *
> sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE;
> } else {
> struct sk_buff * skb;
> + struct sk_buff * rx_skb;
>
> pci_unmap_single(sis_priv->pci_dev,
> sis_priv->rx_ring[entry].bufptr, RX_BUF_SIZE,
> @@ -1787,10 +1788,10 @@ static int sis900_rx(struct net_device *
> }
>
> /* give the socket buffer to upper layers */
> - skb = sis_priv->rx_skbuff[entry];
> - skb_put(skb, rx_size);
> - skb->protocol = eth_type_trans(skb, net_dev);
> - netif_rx(skb);
> + rx_skb = sis_priv->rx_skbuff[entry];
> + skb_put(rx_skb, rx_size);
> + rx_skb->protocol = eth_type_trans(rx_skb, net_dev);
> + netif_rx(rx_skb);
>
> /* some network statistics */
> if ((rx_status & BCAST) == MCAST)
>
> Lots of thanks for Andrew Morton's helpful explanations how to store oops
> infos. Lots of thanks to all the other people trying to help.
> I love to learn! :)
>
> Best Regards
>
> Uwe
Sorry, I forgot to Cc vger.kernel.org - mea culpa!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Dienstag, 22. Mai 2007 22:18 schrieben Sie: On May 20 2007 07:28, Al Viro wrote: On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: Ken? Ball's in your court. As the patch isn't providing a killer feature for 2.6.22, I'd suggest just reverting it for now until the issues are ironed out. Hold it. The real question here is which logics do we want there. IOW, and how many device nodes do we want to appear and _when_ do we want them to appear? min_loop (max_loop?) nodes should appear (but without a backing gendisk), and when they are opened, they should get their gendisk allocated and assigned. Jan Jan, Please stick to the latest revised patch residing in Andrew's mm-tree now. All that I wanted was a possibility to mount up to eight 8 iso images to be mounted parallely at boot time using udev and AVOID fuzzing around with additional nodes in /dev/loop. This desire isn't nonsense at all: For instance, if you run Debian Lenny testing, you need to mount 4 DVD iso images parallely at boot time (at least I do need that) if you do not want to waste time with opening and closing your DVD device at all. Then there may be other desires: a. For instance mounting Christian Marillat's unofficial Debian iso image at boot time (multimedia stuff). b. For instance to mount and run all sampled libraries for helping the wine package to be as compatible as possible (i. e. winetools by Joachim von Thadden) and so on. That means: At least for my personal desire, Ken Chen's latest patch was OK so far. Now, if there is a specific need for mounting up to 256 iso images including whatever technical basis or userspace tools requiries or changings of whatever kind then at least I do not care about the what and why at all. But the facts for now at least go like this: 1. Ken Chen's latest patch, criticised and enhanced by Andrew Morton, acked by Al Viro, is now part of the latest mm-tree. 2. The three patches leading to the disaster of breaking userspace are not yet ripped out of Linus's 2.6.22-rc2-tree. In so far I would deeply appreciate Linus Torvalds to rip put the mentioned patches mentioned, just to avoid future troubles. Yours sincerely Uwe P. S.: 1. The first approach, a common work by Ken Chen and Al Viro, was an approach promising up to 256 iso images to be mounted dynamically on user's demand while really offering only one iso image to be mounted and, after the desire to mount some more at boot time, stop working. I would evaluate that approach as stuff for cabaret laughter, jokin', or simply a terrible bug. 2. I do not like / appreciate discussions on items that seem to be far away from actual user's needs, without being proven by examples of real necessity. Otherwise expressed: Who really needs actually to mount up to 256 iso images using the loop device? I am ready to learn.. :) 3. I have seen this feature of virtual DVD devices under Windoze XP, established for whatever nonsense reason. Question: Who actually needs to mount parallely for instance up to 200 video DVDs wasting Ram like hell? I would call that a kind of fetish, i. e. I do not see the deeper sense of it! The base line for linux as an operating system is: Small and effective is Beautiful, isn't it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops with 2.6.21.1 on an AMD K7 machine
Am Dienstag, 22. Mai 2007 13:18 schrieben Sie:
Am Dienstag, 22. Mai 2007 00:54 schrieben Sie:
On Tue, 22 May 2007 00:28:57 +0200
Uwe Bugla [EMAIL PROTECTED] wrote:
kernel 2.6.21.1 makes my machine Oops about 20 seconds after KDE 3,5 is
brought up showing its graphical login (kdm):
We're completely blind unless we can see that oops info.
Yes.
And I am completely blind if I even once rely on some v4l maintainer who:
a. has absolutely ZERO knowledge about DVB issues
b. is not ready to share power and competence with a second or a third
maintainer
c. smashes down democratic votes (there have been 4 traditional highly
experienced DVB maintainers voting for one person to resolve that issue -
one of them was the old rock Ralph Metzler)
d. reviews code that he absolutely has no idea about and signs it off
e. gives stupid replies on specific questions due to his proven
incompetence
Would you call this man helpful and honest? My answer you can easily guess!
If it reached
/var/log/messages then please send it.
If it didn't please set up netconsole
(Documentation/networking/netconsole.txt)
If for some reason that isn't possible then you couldry switching to
the vga concole (alt-ctl-F1) before the ooops and see if the output
is visible on the VGA screen. If it is there, a digital photo will suit
(you can email it to me and I can stick it on a server somewhere if
you like). The last option is to write the oops info down with a
pencil and type it in again, but that's painful (all the hex addresses
in the stack backtrace can be omitted)
Thanks.
OK, back to the AMD K7 oops issue now:
I in fact never could believe that a simple buggy NIC driver could ever
hang up a whole machine!
So, if someone could be kind enough to explain to me in how far that can
happen I'd be very thankful.
The solution for the 2.6.21.1 oops issue is the following patch, who needs
to flow into vanilla mainline of 2.6.21.x as quick as possible:
--- a/drivers/net/sis900.c
+++ b/drivers/net/sis900.c
@@ -1754,6 +1754,7 @@ static int sis900_rx(struct net_device *
sis_priv-rx_ring[entry].cmdsts = RX_BUF_SIZE;
} else {
struct sk_buff * skb;
+ struct sk_buff * rx_skb;
pci_unmap_single(sis_priv-pci_dev,
sis_priv-rx_ring[entry].bufptr, RX_BUF_SIZE,
@@ -1787,10 +1788,10 @@ static int sis900_rx(struct net_device *
}
/* give the socket buffer to upper layers */
- skb = sis_priv-rx_skbuff[entry];
- skb_put(skb, rx_size);
- skb-protocol = eth_type_trans(skb, net_dev);
- netif_rx(skb);
+ rx_skb = sis_priv-rx_skbuff[entry];
+ skb_put(rx_skb, rx_size);
+ rx_skb-protocol = eth_type_trans(rx_skb, net_dev);
+ netif_rx(rx_skb);
/* some network statistics */
if ((rx_status BCAST) == MCAST)
Lots of thanks for Andrew Morton's helpful explanations how to store oops
infos. Lots of thanks to all the other people trying to help.
I love to learn! :)
Best Regards
Uwe
Sorry, I forgot to Cc vger.kernel.org - mea culpa!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel Oops with 2.6.21.1 on an AMD K7 machine
Hello everybody, kernel 2.6.21.1 makes my machine Oops about 20 seconds after KDE 3,5 is brought up showing its graphical login (kdm): lspci -v, based on a "sane" kernel 2.6.22-rc2 or 2.6.20.11 (with both of them the Oops does not happen at all) looks like this: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 740 Host (rev 01) Flags: bus master, medium devsel, latency 32 Memory at d000 (32-bit, non-prefetchable) [size=64M] Capabilities: [c0] AGP version 2.0 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=02, sec-latency=64 I/O behind bridge: a000-afff Memory behind bridge: cfd0-cfef Prefetchable memory behind bridge: bfa0-cfbf 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 04) Flags: bus master, medium devsel, latency 0 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller Flags: medium devsel I/O ports at 0c00 [size=32] 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 128 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at ff00 [size=16] 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) Subsystem: C-Media Electronics Inc Unknown device 0300 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at d800 [size=256] I/O ports at d400 [size=128] Capabilities: [48] Power Management version 2 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd. K7SOM+ 5.2C Motherboard Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff7000 (32-bit, non-prefetchable) [size=4K] 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd. K7SOM+ 5.2C Motherboard Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at cfff8000 (32-bit, non-prefetchable) [size=4K] 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd. K7SOM+ 5.2C Motherboard Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at cfff9000 (32-bit, non-prefetchable) [size=4K] 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 5470 Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at cfffa000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) Subsystem: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet Adapter Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at d000 [size=256] Memory at cfff6000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at cffc [disabled] [size=128K] Capabilities: [40] Power Management version 2 00:09.0 SCSI storage controller: Adaptec AIC-7861 (rev 01) Flags: bus master, medium devsel, latency 64, IRQ 5 I/O ports at dc00 [disabled] [size=256] Memory at cfffb000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at cffe [disabled] [size=64K] 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at cc00 [size=128] Memory at cfff5f80 (32-bit, non-prefetchable) [size=128] Expansion ROM at cffa [disabled] [size=128K] Capabilities: [dc] Power Management version 1 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter (prog-if 00 [VGA]) Subsystem: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter Flags: 66MHz, medium devsel BIST result: 00 Memory at c000 (32-bit, prefetchable) [size=128M] Memory at cfee (32-bit, non-prefetchable) [size=128K] I/O ports at ac00 [size=128] Capabilities: [40] Power Management
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Montag, 21. Mai 2007 22:48 schrieben Sie:
> On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > The easiest way is to reinstate max_loop and create "max_loop" device
> > up front at module load time. However, that will lose all the "fancy
> > on-demand device instantiation feature".
> >
> > So I propose we do the following:
> >
> > 1. have the module honor "max_loop" parameter and create that many
> > device upfront on module load (max_loop will also be a hard max) iff
> > user specify the parameter.
> > 2. if max_loop is not specified, default create 8 loop device. User
> > can extent more loop device by create device node themselves and have
> > kernel automatically instantiate loop device on-demand.
> >
> > Is this acceptable? Patch in a bit.
>
> Could people who has problem with loop device please test this? I
> tested it on my Ubuntu feisty distribution and it works fine. Though I
> typically don't use loop device at all.
>
> ---
>
> The kernel on-demand loop device instantiation breaks several user
> space tools as the tools are not ready to cope with the "on-demand
> feature". Fix it by instantiate default 8 loop devices and also
> reinstate max_loop module parameter.
>
> Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 5526ead..0aae8d8 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1354,7 +1354,7 @@ #endif
> */
> static int max_loop;
> module_param(max_loop, int, 0);
> -MODULE_PARM_DESC(max_loop, "obsolete, loop device is created on-demand");
> +MODULE_PARM_DESC(max_loop, "Maximum number of loop devices");
> MODULE_LICENSE("GPL");
> MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
>
> @@ -1462,34 +1462,66 @@ static struct kobject *loop_probe(dev_t
> return kobj;
> }
>
> -static int __init loop_init(void)
> -{
> - if (register_blkdev(LOOP_MAJOR, "loop"))
> - return -EIO;
> - blk_register_region(MKDEV(LOOP_MAJOR, 0), 1UL << MINORBITS,
> - THIS_MODULE, loop_probe, NULL, NULL);
> -
> - if (max_loop) {
> - printk(KERN_INFO "loop: the max_loop option is obsolete "
> - "and will be removed in March 2008\n");
> -
> - }
> - printk(KERN_INFO "loop: module loaded\n");
> - return 0;
> -}
> -
> static void __exit loop_exit(void)
> {
> + unsigned long range;
> struct loop_device *lo, *next;
>
> + range = max_loop ? max_loop : 1UL << MINORBITS;
> +
> list_for_each_entry_safe(lo, next, _devices, lo_list)
> loop_del_one(lo);
>
> - blk_unregister_region(MKDEV(LOOP_MAJOR, 0), 1UL << MINORBITS);
> + blk_unregister_region(MKDEV(LOOP_MAJOR, 0), range);
> if (unregister_blkdev(LOOP_MAJOR, "loop"))
> printk(KERN_WARNING "loop: cannot unregister blkdev\n");
> }
>
> +static int __init loop_init(void)
> +{
> + int i, nr;
> + unsigned long range;
> +
> + /*
> + * loop module now has a feature to instantiate underlying device
> + * structure on-demand, provided that there is an access dev node.
> + * However, this will not work well with user space tool that doesn't
> + * know about such "feature". In order to not break any existing
> + * tool, we do the following:
> + *
> + * (1) if max_loop is specified, create that many upfront, and this
> + * also becomes a hard limit.
> + * (2) if max_loop is not specified, create 8 loop device on module
> + * load, user can further extend loop device by create dev node
> + * themselves and have kernel automatically instantiate actual
> + * device on-demand.
> + */
> + if (max_loop) {
> + nr = max_loop;
> + range = max_loop;
> + } else {
> + nr = 8;
> + range = 1UL << MINORBITS;
> + }
> +
> + if (register_blkdev(LOOP_MAJOR, "loop"))
> + return -EIO;
> + blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
> + THIS_MODULE, loop_probe, NULL, NULL);
> +
> + for (i = 0; i < nr; i++) {
> + if (!loop_init_one(i))
> + goto err;
> + }
> +
> + printk(KERN_INFO "loop: module loaded\n");
> + return 0;
> +err:
> + loop_exit();
> + printk(KERN_INFO "loop: out of memory\n");
> + return -ENOMEM;
> +}
> +
> module_init(loop_init);
> module_exit(loop_exit);
Thank you, Ken :)
Excellent work, everything runs as expected.
Starting compilation of 2.6.22-rc2 I get the following nasty messages:
scripts/kconfig/conf -s arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config
symbol 'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_GETH'
refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
symbol 'KEYBOARD_ATARI'
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Montag, 21. Mai 2007 18:37 schrieben Sie: > On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote: > > yes and no. in that commit, I automatically create n+1 device when > > loop device n is created, allergically was tested to be fine with > > casual usage of "losetup" and "mount -o loop". However, there is a > > bug in that commit when loop.c was compiled as a module. And when Al > > fixed it, he also removed that magic "n+1" trick. > > > > Nevertheless, yes, I'm guilty of introducing the new behavior. > > The easiest way is to reinstate max_loop and create "max_loop" device > up front at module load time. However, that will lose all the "fancy > on-demand device instantiation feature". > > So I propose we do the following: > > 1. have the module honor "max_loop" parameter and create that many > device upfront on module load (max_loop will also be a hard max) iff > user specify the parameter. > 2. if max_loop is not specified, default create 8 loop device. User > can extent more loop device by create device node themselves and have > kernel automatically instantiate loop device on-demand. Sorry, Ken: My question on point 2 would be: Does "User can extent more loop device by create device node themselves and..." correspond or conflict to working with udev? > > Is this acceptable? Patch in a bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Montag, 21. Mai 2007 08:40 schrieben Sie: > On 5/20/07, Ken Chen <[EMAIL PROTECTED]> wrote: > > On 5/19/07, Ray Lee <[EMAIL PROTECTED]> wrote: > > > Yeah, that's the only one left. I was hoping it wasn't that one, as it > > > claimed to have been tested extensively. Guess it wasn't tested with > > > udev. > > > > > > Ken? Ball's in your court. As the patch isn't providing a killer > > > feature for 2.6.22, I'd suggest just reverting it for now until the > > > issues are ironed out. > > > > The real solution is to have the user space tool to create these > > device nodes in advance. > > Maybe. But requiring people upgrade their userspace tools or setup for > 2.6.22 isn't a reasonable solution. > > > The original loop patch was coded such that when we open a loop device > > N, the immediate adjacent device "N + 1" is created. This will keep > > "mount -o loop" happy because it typically does a linear scan to find > > a free device. This might be somewhat hackary, but certainly will be > > backward compatible before user space solution is deployed. > > Except userspace is currently expecting 8 loop nodes upon bootup. > Creating n+1 when n is opened is good, but racy if userspace tries to > mount serveral loop devices in parallel. > > If the loop device instantiates 8 (or max_loop) upon init, then we're > compatible with how things are being done in 2.6.21 and earlier. > > > However, the code was removed by Al in this commit: > > > > commit 07002e995638b83a6987180f43722a0eb39d4932 > > Author: Al Viro <[EMAIL PROTECTED]> > > Date: Sat May 12 16:23:15 2007 -0400 > > > > fix the dynamic allocation and probe in loop.c > > No, backing that code out wasn't good enough -- the reporter tested > reverting both of Al's patches out and was still getting errors on > boot. It took reverting your original one out as well to make it work. Yes. I reverted three in fact. Please see my latest entry in this thread to read what I did to make this work for now. > > So, a compromise? Let's start with 8 (or max_loop) populated, and then > we can move forward separately with teaching userspace new loop > tricks. Yes. Good idea! The reason why I need 2.6.22-rc2 and why I cannot work with 2.6.21.1 is that I get a kernel oops (hangup) with 2.6.21.1 about 20 seconds after login. The machine is an AMD K7 with but SiS chipsets / controllers onboard. Responsible for that kernel oops with 2.6.21.1 is supposedly the whole ide layer plus sis5513.c. In so far, pulling all ide layer changes plus the sis5513.c patch from 2.6.22-rc2 into mainline of 2.6.21 would definitely be a very good idea. Thanks for the quick help, especially to Ray. Best Regards Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Montag, 21. Mai 2007 08:40 schrieben Sie: On 5/20/07, Ken Chen [EMAIL PROTECTED] wrote: On 5/19/07, Ray Lee [EMAIL PROTECTED] wrote: Yeah, that's the only one left. I was hoping it wasn't that one, as it claimed to have been tested extensively. Guess it wasn't tested with udev. Ken? Ball's in your court. As the patch isn't providing a killer feature for 2.6.22, I'd suggest just reverting it for now until the issues are ironed out. The real solution is to have the user space tool to create these device nodes in advance. Maybe. But requiring people upgrade their userspace tools or setup for 2.6.22 isn't a reasonable solution. The original loop patch was coded such that when we open a loop device N, the immediate adjacent device N + 1 is created. This will keep mount -o loop happy because it typically does a linear scan to find a free device. This might be somewhat hackary, but certainly will be backward compatible before user space solution is deployed. Except userspace is currently expecting 8 loop nodes upon bootup. Creating n+1 when n is opened is good, but racy if userspace tries to mount serveral loop devices in parallel. If the loop device instantiates 8 (or max_loop) upon init, then we're compatible with how things are being done in 2.6.21 and earlier. However, the code was removed by Al in this commit: commit 07002e995638b83a6987180f43722a0eb39d4932 Author: Al Viro [EMAIL PROTECTED] Date: Sat May 12 16:23:15 2007 -0400 fix the dynamic allocation and probe in loop.c No, backing that code out wasn't good enough -- the reporter tested reverting both of Al's patches out and was still getting errors on boot. It took reverting your original one out as well to make it work. Yes. I reverted three in fact. Please see my latest entry in this thread to read what I did to make this work for now. So, a compromise? Let's start with 8 (or max_loop) populated, and then we can move forward separately with teaching userspace new loop tricks. Yes. Good idea! The reason why I need 2.6.22-rc2 and why I cannot work with 2.6.21.1 is that I get a kernel oops (hangup) with 2.6.21.1 about 20 seconds after login. The machine is an AMD K7 with but SiS chipsets / controllers onboard. Responsible for that kernel oops with 2.6.21.1 is supposedly the whole ide layer plus sis5513.c. In so far, pulling all ide layer changes plus the sis5513.c patch from 2.6.22-rc2 into mainline of 2.6.21 would definitely be a very good idea. Thanks for the quick help, especially to Ray. Best Regards Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Montag, 21. Mai 2007 18:37 schrieben Sie: On 5/21/07, Ken Chen [EMAIL PROTECTED] wrote: yes and no. in that commit, I automatically create n+1 device when loop device n is created, allergically was tested to be fine with casual usage of losetup and mount -o loop. However, there is a bug in that commit when loop.c was compiled as a module. And when Al fixed it, he also removed that magic n+1 trick. Nevertheless, yes, I'm guilty of introducing the new behavior. The easiest way is to reinstate max_loop and create max_loop device up front at module load time. However, that will lose all the fancy on-demand device instantiation feature. So I propose we do the following: 1. have the module honor max_loop parameter and create that many device upfront on module load (max_loop will also be a hard max) iff user specify the parameter. 2. if max_loop is not specified, default create 8 loop device. User can extent more loop device by create device node themselves and have kernel automatically instantiate loop device on-demand. Sorry, Ken: My question on point 2 would be: Does User can extent more loop device by create device node themselves and... correspond or conflict to working with udev? Is this acceptable? Patch in a bit. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Montag, 21. Mai 2007 22:48 schrieben Sie:
On 5/21/07, Ken Chen [EMAIL PROTECTED] wrote:
The easiest way is to reinstate max_loop and create max_loop device
up front at module load time. However, that will lose all the fancy
on-demand device instantiation feature.
So I propose we do the following:
1. have the module honor max_loop parameter and create that many
device upfront on module load (max_loop will also be a hard max) iff
user specify the parameter.
2. if max_loop is not specified, default create 8 loop device. User
can extent more loop device by create device node themselves and have
kernel automatically instantiate loop device on-demand.
Is this acceptable? Patch in a bit.
Could people who has problem with loop device please test this? I
tested it on my Ubuntu feisty distribution and it works fine. Though I
typically don't use loop device at all.
---
The kernel on-demand loop device instantiation breaks several user
space tools as the tools are not ready to cope with the on-demand
feature. Fix it by instantiate default 8 loop devices and also
reinstate max_loop module parameter.
Signed-off-by: Ken Chen [EMAIL PROTECTED]
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 5526ead..0aae8d8 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1354,7 +1354,7 @@ #endif
*/
static int max_loop;
module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, obsolete, loop device is created on-demand);
+MODULE_PARM_DESC(max_loop, Maximum number of loop devices);
MODULE_LICENSE(GPL);
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
@@ -1462,34 +1462,66 @@ static struct kobject *loop_probe(dev_t
return kobj;
}
-static int __init loop_init(void)
-{
- if (register_blkdev(LOOP_MAJOR, loop))
- return -EIO;
- blk_register_region(MKDEV(LOOP_MAJOR, 0), 1UL MINORBITS,
- THIS_MODULE, loop_probe, NULL, NULL);
-
- if (max_loop) {
- printk(KERN_INFO loop: the max_loop option is obsolete
- and will be removed in March 2008\n);
-
- }
- printk(KERN_INFO loop: module loaded\n);
- return 0;
-}
-
static void __exit loop_exit(void)
{
+ unsigned long range;
struct loop_device *lo, *next;
+ range = max_loop ? max_loop : 1UL MINORBITS;
+
list_for_each_entry_safe(lo, next, loop_devices, lo_list)
loop_del_one(lo);
- blk_unregister_region(MKDEV(LOOP_MAJOR, 0), 1UL MINORBITS);
+ blk_unregister_region(MKDEV(LOOP_MAJOR, 0), range);
if (unregister_blkdev(LOOP_MAJOR, loop))
printk(KERN_WARNING loop: cannot unregister blkdev\n);
}
+static int __init loop_init(void)
+{
+ int i, nr;
+ unsigned long range;
+
+ /*
+ * loop module now has a feature to instantiate underlying device
+ * structure on-demand, provided that there is an access dev node.
+ * However, this will not work well with user space tool that doesn't
+ * know about such feature. In order to not break any existing
+ * tool, we do the following:
+ *
+ * (1) if max_loop is specified, create that many upfront, and this
+ * also becomes a hard limit.
+ * (2) if max_loop is not specified, create 8 loop device on module
+ * load, user can further extend loop device by create dev node
+ * themselves and have kernel automatically instantiate actual
+ * device on-demand.
+ */
+ if (max_loop) {
+ nr = max_loop;
+ range = max_loop;
+ } else {
+ nr = 8;
+ range = 1UL MINORBITS;
+ }
+
+ if (register_blkdev(LOOP_MAJOR, loop))
+ return -EIO;
+ blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
+ THIS_MODULE, loop_probe, NULL, NULL);
+
+ for (i = 0; i nr; i++) {
+ if (!loop_init_one(i))
+ goto err;
+ }
+
+ printk(KERN_INFO loop: module loaded\n);
+ return 0;
+err:
+ loop_exit();
+ printk(KERN_INFO loop: out of memory\n);
+ return -ENOMEM;
+}
+
module_init(loop_init);
module_exit(loop_exit);
Thank you, Ken :)
Excellent work, everything runs as expected.
Starting compilation of 2.6.22-rc2 I get the following nasty messages:
scripts/kconfig/conf -s arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config
symbol 'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_GETH'
refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:182:warning: 'select' used by config
symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
But,
Kernel Oops with 2.6.21.1 on an AMD K7 machine
Hello everybody, kernel 2.6.21.1 makes my machine Oops about 20 seconds after KDE 3,5 is brought up showing its graphical login (kdm): lspci -v, based on a sane kernel 2.6.22-rc2 or 2.6.20.11 (with both of them the Oops does not happen at all) looks like this: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 740 Host (rev 01) Flags: bus master, medium devsel, latency 32 Memory at d000 (32-bit, non-prefetchable) [size=64M] Capabilities: [c0] AGP version 2.0 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=02, sec-latency=64 I/O behind bridge: a000-afff Memory behind bridge: cfd0-cfef Prefetchable memory behind bridge: bfa0-cfbf 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 04) Flags: bus master, medium devsel, latency 0 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller Flags: medium devsel I/O ports at 0c00 [size=32] 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 128 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at ff00 [size=16] 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) Subsystem: C-Media Electronics Inc Unknown device 0300 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at d800 [size=256] I/O ports at d400 [size=128] Capabilities: [48] Power Management version 2 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd. K7SOM+ 5.2C Motherboard Flags: bus master, medium devsel, latency 64, IRQ 5 Memory at cfff7000 (32-bit, non-prefetchable) [size=4K] 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd. K7SOM+ 5.2C Motherboard Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at cfff8000 (32-bit, non-prefetchable) [size=4K] 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd. K7SOM+ 5.2C Motherboard Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at cfff9000 (32-bit, non-prefetchable) [size=4K] 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 5470 Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at cfffa000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) Subsystem: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet Adapter Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at d000 [size=256] Memory at cfff6000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at cffc [disabled] [size=128K] Capabilities: [40] Power Management version 2 00:09.0 SCSI storage controller: Adaptec AIC-7861 (rev 01) Flags: bus master, medium devsel, latency 64, IRQ 5 I/O ports at dc00 [disabled] [size=256] Memory at cfffb000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at cffe [disabled] [size=64K] 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at cc00 [size=128] Memory at cfff5f80 (32-bit, non-prefetchable) [size=128] Expansion ROM at cffa [disabled] [size=128K] Capabilities: [dc] Power Management version 1 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter (prog-if 00 [VGA]) Subsystem: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter Flags: 66MHz, medium devsel BIST result: 00 Memory at c000 (32-bit, prefetchable) [size=128M] Memory at cfee (32-bit, non-prefetchable) [size=128K] I/O ports at ac00 [size=128] Capabilities: [40] Power Management version
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Sonntag, 20. Mai 2007 18:16 schrieben Sie: > On Sun, 2007-05-20 at 09:10 -0700, Ray Lee wrote: > > On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote: > > > On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote: > > > > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote: > > > > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: > > > > > > Ken? Ball's in your court. As the patch isn't providing a killer > > > > > > feature for 2.6.22, I'd suggest just reverting it for now until > > > > > > the issues are ironed out. > > > > > > > > > > Hold it. The real question here is which logics do we want there. > > > > > IOW, and how many device nodes do we want to appear and _when_ do > > > > > we want them to appear? > > > > > > > > The when part is what looks to make it racy. I'm guessing that we're > > > > relying on udev to create those loop nodes. If so, I think any scheme > > > > that creates more on demand would give transient mount errors while > > > > it's waiting on udev to create more nodes. > > > > > > > > Perhaps if we were to start with 8 loop nodes at init (as we have in > > > > 2.6.21), and then always maintain a margin of 8 (or 4, or...) when > > > > they start being used or detached? > > > > > > Until the tools can request dynamic loop device allocation from the > > > kernel before they want to use the device, you can create as many as > > > needed "static" loop* nodes in /lib/udev/devices/, which will be > > > copied to /dev/ early on every bootup. > > > > Except that's different than current behavior presented to userspace. > > IOW, we broke userspace for anyone using udev. Which is, y'know, a lot > > of us. > > > > We're at -rc2 right now. Given that, it looks like we have two > > options. First is to revert all this for now and try again when the > > patch has had more testing and agreement (as this isn't a major > > feature we're talking about here; it's effectively just a cleanup that > > happened to have unfortunate side-effects). > > > > The second option is that we could have the loop device start with 8 > > nodes populated, which would match current behavior. > > > > A third option of requiring new userspace for 2.6.22 is a non-starter. > > Right, providing "preallocated" devices, 8 or the number given in > max_loop, sounds like the best option until the tools can handle that. > > Thanks, > Kay OK people, this is what I did just to resolve the issue for now: 1. copied loop.c from 2.6.21 into the 2.6.22-rc2 tree 2. changed exactly two entries from "invalidate_bdev(bdev, 0)" to "invalidate_bdev(bdev)" Output is: a. a compilable kernel b. all four iso images are mounted as expected Andrey's path however (i. e. copying his attached version of loop.c into the 2.6.22-rc2 kernel tree) led to: a. an incompilable kernel b. endless messages trying to compile loop.c going like this (just a part of them - not complete anyway!): drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c: In function 'loop_register_transfer': drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program Thanks to Ray! Well done! Best regards Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Sonntag, 20. Mai 2007 08:58 schrieben Sie: > On Sunday 20 May 2007, Al Viro wrote: > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: > > > Ken? Ball's in your court. As the patch isn't providing a killer > > > feature for 2.6.22, I'd suggest just reverting it for now until the > > > issues are ironed out. > > > > Hold it. The real question here is which logics do we want there. > > IOW, and how many device nodes do we want to appear and _when_ do > > we want them to appear? > > of course we'd like to use exactly as many (or few) nodes as are in use > right now and without fixed limit for their number; which implies that > nodes should appear and go on as needed basis. > > But right now there is no kernel mechanism that user level program could > use to request allocation of new loop node. I won't discuss whether it is > legitimate to mandate new version of util-linux for kernel 2.6.22; but it > is obvious that any kernel patch that adds such mechanism goes far beyond > simple bug fix and is not acceptable at this stage. > > So let's revert this change and discuss it for post-2.6.22 timeframe. Hi, I am of course not a fan of limiting the maximum of available loops to 8. My question / proposal for now would be: Could anybody of you please be kind enough and write / provide me a counter patch supplying me: a. a compilable 2.6.22-rc2 kernel b. a loop device that can mount up to 8 iso-images I would prefer this thing as outline attachment due to Email client wordwrapping problems. Looking happily forward to a functionable counter patch to resolve the current issue as a compromise solution, Best regards and thanks Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Sonntag, 20. Mai 2007 08:58 schrieben Sie: On Sunday 20 May 2007, Al Viro wrote: On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: Ken? Ball's in your court. As the patch isn't providing a killer feature for 2.6.22, I'd suggest just reverting it for now until the issues are ironed out. Hold it. The real question here is which logics do we want there. IOW, and how many device nodes do we want to appear and _when_ do we want them to appear? of course we'd like to use exactly as many (or few) nodes as are in use right now and without fixed limit for their number; which implies that nodes should appear and go on as needed basis. But right now there is no kernel mechanism that user level program could use to request allocation of new loop node. I won't discuss whether it is legitimate to mandate new version of util-linux for kernel 2.6.22; but it is obvious that any kernel patch that adds such mechanism goes far beyond simple bug fix and is not acceptable at this stage. So let's revert this change and discuss it for post-2.6.22 timeframe. Hi, I am of course not a fan of limiting the maximum of available loops to 8. My question / proposal for now would be: Could anybody of you please be kind enough and write / provide me a counter patch supplying me: a. a compilable 2.6.22-rc2 kernel b. a loop device that can mount up to 8 iso-images I would prefer this thing as outline attachment due to Email client wordwrapping problems. Looking happily forward to a functionable counter patch to resolve the current issue as a compromise solution, Best regards and thanks Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Sonntag, 20. Mai 2007 18:16 schrieben Sie: On Sun, 2007-05-20 at 09:10 -0700, Ray Lee wrote: On 5/20/07, Kay Sievers [EMAIL PROTECTED] wrote: On 5/20/07, Ray Lee [EMAIL PROTECTED] wrote: On 5/19/07, Al Viro [EMAIL PROTECTED] wrote: On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: Ken? Ball's in your court. As the patch isn't providing a killer feature for 2.6.22, I'd suggest just reverting it for now until the issues are ironed out. Hold it. The real question here is which logics do we want there. IOW, and how many device nodes do we want to appear and _when_ do we want them to appear? The when part is what looks to make it racy. I'm guessing that we're relying on udev to create those loop nodes. If so, I think any scheme that creates more on demand would give transient mount errors while it's waiting on udev to create more nodes. Perhaps if we were to start with 8 loop nodes at init (as we have in 2.6.21), and then always maintain a margin of 8 (or 4, or...) when they start being used or detached? Until the tools can request dynamic loop device allocation from the kernel before they want to use the device, you can create as many as needed static loop* nodes in /lib/udev/devices/, which will be copied to /dev/ early on every bootup. Except that's different than current behavior presented to userspace. IOW, we broke userspace for anyone using udev. Which is, y'know, a lot of us. We're at -rc2 right now. Given that, it looks like we have two options. First is to revert all this for now and try again when the patch has had more testing and agreement (as this isn't a major feature we're talking about here; it's effectively just a cleanup that happened to have unfortunate side-effects). The second option is that we could have the loop device start with 8 nodes populated, which would match current behavior. A third option of requiring new userspace for 2.6.22 is a non-starter. Right, providing preallocated devices, 8 or the number given in max_loop, sounds like the best option until the tools can handle that. Thanks, Kay OK people, this is what I did just to resolve the issue for now: 1. copied loop.c from 2.6.21 into the 2.6.22-rc2 tree 2. changed exactly two entries from invalidate_bdev(bdev, 0) to invalidate_bdev(bdev) Output is: a. a compilable kernel b. all four iso images are mounted as expected Andrey's path however (i. e. copying his attached version of loop.c into the 2.6.22-rc2 kernel tree) led to: a. an incompilable kernel b. endless messages trying to compile loop.c going like this (just a part of them - not complete anyway!): drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1350: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c:1351: error: stray '\240' in program drivers/block/loop.c: In function 'loop_register_transfer': drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program drivers/block/loop.c:1367: error: stray '\240' in program Thanks to Ray! Well done! Best regards Uwe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in 2.6.22-rc2: loop mount limited to one single iso image
Hi, I am running Debian Etch 4.0 stable in connection with udev. In kernel 2.6.22-rc2 the number of available loop mounts is reduced from 8 (conventional standard of preceding 2.6 kernels) to 1. Symptom: If you try to mount more than one single iso-image with the loop parameter you are receiving the following message during system boot: "mount: could not find any free loop device" Kernel 2.6.20.11 does not show that problem. Question: Can someone reading this confirm and reproduce that problem? If yes: Are there any fixes available? Thanks and Regards Uwe -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in 2.6.22-rc2: loop mount limited to one single iso image
Hi, I am running Debian Etch 4.0 stable in connection with udev. In kernel 2.6.22-rc2 the number of available loop mounts is reduced from 8 (conventional standard of preceding 2.6 kernels) to 1. Symptom: If you try to mount more than one single iso-image with the loop parameter you are receiving the following message during system boot: mount: could not find any free loop device Kernel 2.6.20.11 does not show that problem. Question: Can someone reading this confirm and reproduce that problem? If yes: Are there any fixes available? Thanks and Regards Uwe -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in 2.6.22-rc1: loop devices limited to one single device
Hi, The patch against loop.c is neither a fix, nor does it create loop devices on demand: Facts are instead, at least on my machine: The number of available loop devices is reduced from 8 (conventional standard of preceding 2.6 kernels) to 1. The consequence is: If you have to mount more than one single iso-image with the loop parameter you are receiving the following message during system boot: "mount: could not find any free loop device" Regards Uwe -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in 2.6.22-rc1: loop devices limited to one single device
Hi, The patch against loop.c is neither a fix, nor does it create loop devices on demand: Facts are instead, at least on my machine: The number of available loop devices is reduced from 8 (conventional standard of preceding 2.6 kernels) to 1. The consequence is: If you have to mount more than one single iso-image with the loop parameter you are receiving the following message during system boot: mount: could not find any free loop device Regards Uwe -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Mon, 07 May 2007 17:54:29 -0300 Von: Mauro Carvalho Chehab <[EMAIL PROTECTED]> An: Manu Abraham <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) > Hi Manu, > > > From my side, quite some time has been put forward to write that mail. > > Inspite of that if you feel that you do have to go your own way, then > > it is completely upto you. I would say: do as you feel in such a case. > > The point is that those issues are pending for a long time, and they > should be solved, especially the module removal issue (*) > > If you are so afraid about applying those changes, maybe the better is > to apply those patches at v4l-dvb tree and at -mm, asking people to > test. > > We may hold their commit on kernel mainstream until the next kernel > release, if nobody complains about, or otherwise revert the changes, if > they proofed to cause troubles at dst and/or dvb-bt8xx. > > Also, you (or others) may write another approach keeping the fixes with > an strategy more adequate for dst. > > Do you agree with this way? > > -- > Cheers, > Mauro > > (*) Currently, dst can be removed only with "rmmod -f", due to a wrong > usage count. With Trent's patches, this were fixed. Mauro, First of all, Manu is not a machine shitting out solutions on other one's pressure. And he is doing right so far, as far as what happened. Second: You should do some self-reflection on the damage you did on the human layer. You appear like not even having any intention or idea on how to do that, you just behave technocratic and cold, you are just doing "I-AM-THE-BOSS, AND-NOTHING-GOES-WITHOUT-ME"-politics, that's all. Even if you do not have at least partially any idea about it all, you just try to rule "godlike", you know. Not everybody agrees with that ruling style, just a hint for you that you do not ever want to see, because you prefer to be blind in order to rule, to move on to the daily dayplan, as if nothing happened. But there happened many things. But you just prefer to be blind. Currently me and Manu are working on a long lasting project very harmonizing, which I never believed to be possible at all, but we do work together :-). And as long as the the ruler behaviour and the ruling structure of linuxtv.org keeps on behaving like this (including all the nasty people like mrechberger for instance), then let me tell you that I care a shit about what is being pulled into the kernel and what is not, man! Now if you cannot take that I feel sorry, but he whole system around here gotta be changed as far as maintainership is concerned. You cannot go on like this, Mr. Chehab, and even if you keep on ignoring this message you will be producing nothing but damage in the end. Noone was born to act and behave like a nodding nigger in front of you - and if you do not want to take that, well, then you're strictly obsolete, man! Without any politeness Uwe > > > ___ > linux-dvb mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Mon, 07 May 2007 17:54:29 -0300 Von: Mauro Carvalho Chehab [EMAIL PROTECTED] An: Manu Abraham [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) Hi Manu, From my side, quite some time has been put forward to write that mail. Inspite of that if you feel that you do have to go your own way, then it is completely upto you. I would say: do as you feel in such a case. The point is that those issues are pending for a long time, and they should be solved, especially the module removal issue (*) If you are so afraid about applying those changes, maybe the better is to apply those patches at v4l-dvb tree and at -mm, asking people to test. We may hold their commit on kernel mainstream until the next kernel release, if nobody complains about, or otherwise revert the changes, if they proofed to cause troubles at dst and/or dvb-bt8xx. Also, you (or others) may write another approach keeping the fixes with an strategy more adequate for dst. Do you agree with this way? -- Cheers, Mauro (*) Currently, dst can be removed only with rmmod -f, due to a wrong usage count. With Trent's patches, this were fixed. Mauro, First of all, Manu is not a machine shitting out solutions on other one's pressure. And he is doing right so far, as far as what happened. Second: You should do some self-reflection on the damage you did on the human layer. You appear like not even having any intention or idea on how to do that, you just behave technocratic and cold, you are just doing I-AM-THE-BOSS, AND-NOTHING-GOES-WITHOUT-ME-politics, that's all. Even if you do not have at least partially any idea about it all, you just try to rule godlike, you know. Not everybody agrees with that ruling style, just a hint for you that you do not ever want to see, because you prefer to be blind in order to rule, to move on to the daily dayplan, as if nothing happened. But there happened many things. But you just prefer to be blind. Currently me and Manu are working on a long lasting project very harmonizing, which I never believed to be possible at all, but we do work together :-). And as long as the the ruler behaviour and the ruling structure of linuxtv.org keeps on behaving like this (including all the nasty people like mrechberger for instance), then let me tell you that I care a shit about what is being pulled into the kernel and what is not, man! Now if you cannot take that I feel sorry, but he whole system around here gotta be changed as far as maintainership is concerned. You cannot go on like this, Mr. Chehab, and even if you keep on ignoring this message you will be producing nothing but damage in the end. Noone was born to act and behave like a nodding nigger in front of you - and if you do not want to take that, well, then you're strictly obsolete, man! Without any politeness Uwe ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Fri, 04 May 2007 02:31:49 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) > Markus Rechberger wrote: > > > I mean the mail from Helge Hafting (thread [linux-dvb] Critical > > points about kernel 2.6.21 and pseudo-authorities) at the very first > > beginning. > > > > I am replying to this mail, just because someone's spreading lies all > around. > On the mentioned thread, what i wrote (and that was the only mail from > my side): > > There is a saying: "He who lives by the sword, dies by the sword." Hi Manu, The saying that you stated is a very christian one. I perhaps should state that I am 47 years old now, raised in in utmost reactionary region called Bavaria (Western Germany), and also raised by parents of Russian / Polonian origin who shared the Nazi regime with the usual "I-do-not-want-to-talk-about-it-and-I-do-not-want-to-feel-responsible-about-it "-behaviour. And I am very much not only interested in german post-war history, but I simply love to write provocative letters or mails to make my conviction utmost clear that all this capitalist bullshit around us should vanish and shrink and be overcome some day. Basic christian ideals are very close to basic marxist ideas. The one who never does perceive that is a real poor human being in my eyes, if not to say: a complete idiot or a system-conforming hypocrite. BUT: I in fact do not read this "saying" for the first time: In my personal experience (feel very sorry about it, but it's true) it has always truthfully been an excuse for persons being strongly limited on what I would call utmost primitive instincts like greed or rapacity (i. e. the utmost perfect sounding "would-like-to-capitalists", if not to say: the perfect slaves or: the perfect counterrevolutionaries or strike-breakers, if not to say: the utmost perfect asscreepers). Please forgive me for that statement, but I am simply stating my personal experiences very truthfully, without playing any politics, but just telling you my "personal truth" or the sum of all my personal life experience unfortunately bound to that. And if there is discussion needed on that we should do it private or anyway on some other thread, but definitely not on this one. Hints to help you to understand the difference: 1. There is a GPL license written by Richard Stallman whose origin I do not know: Its essence is the philosophy to share and to be highly transparent as far as information level is concerned. 2. There is a saying by Linus in which he states the best choice he ever did was conforming his work to the terms of Richard Stallman, the GPL. 3. Wikipedia says that Linus's father was no christian at all, but simply a communist. See, Manu, there are deeply primitive instinct-driven hypocrites around like hell, but there are also truthful human beings around. But: The Internet does not provide a platform to find out who is who and what is what. The Internet may be necessary, but in the end it's just a drag, isn't it? Sincerely Uwe > > > Original Message > Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and > pseudo-authorities > Date: Tue, 01 May 2007 04:19:41 +0400 > From: Manu Abraham <[EMAIL PROTECTED]> > To: Uwe Bugla <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > linux-kernel@vger.kernel.org, [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> <[EMAIL PROTECTED] > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > Uwe Bugla wrote: > > > 1. You utmost personally are responsible for 4 ununsable kernels, as > far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! > > 2. You did not even want to imply to resolve that issue by incarnating > that "community and synergy principle" that linux community needs to > exist at all, but you just perverted it by flaming capable people - > > You mean like this: > > > Original Message > Subject: kernel patch practice in 2.6.13-mm2 > Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) > From: Uwe Bugla <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > CC: [EMA
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Fri, 4 May 2007 00:06:51 +0200 Von: "Markus Rechberger" <[EMAIL PROTECTED]> An: "Manu Abraham" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) > On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > Markus Rechberger wrote: > > > On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > >> Mauro Carvalho Chehab wrote: > > >> > Enough. Let's stop arguing non technical issues. > > >> > > > >> > If either one of you have any technical argue against the Trent's > > >> > patches, please point where the fix is wrong. Otherwise, if you > wish, > > >> > you may send an acked-by agreeing with the fix. > > >> > > > >> > > >> Why don't you stop this childish behaviour ? > > >> > > >> After explaining to you the reasons in the previous mail: > > >> being the author and maintainer of dst/dst_ca and maintainer of > > >> dvb-bt8xx, i NACK this change > > >> > > >> (1) You aren't DVB maintainer > > > > > > I've seen that too often already, now we could point to a mail someone > > > sent to Uwe regarding maintainership. > > > > > > FYI, I have never written to Uwe regarding any sort of maintainership. > > You seem to be quite up with an overdose of drugs > > > > I mean the mail from Helge Hafting (thread [linux-dvb] Critical > points about kernel 2.6.21 and pseudo-authorities) at the very first > beginning. > > > From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from > > my side to Uwe, none of which has a topic whatsoever you say. Only the > > first mail was a private mail and that is CC'd to Johannes as well. > > > > Firstly you seem to play politics by getting Uwe to flame me, then when > > it backfired, you are trying to play tricks with the rest of the > > community as well, by spreading nonsense statements. > > > > I sent several comments to Uwe to stop flaming, Trent was in the CC > sometimes I never wrote that he should flame on anyone. > I can simply forward you all mails I sent to Uwe there's not one bad mail. > > My point is moreover to get that issue sorted out by either accepting > his "proposal" or stating out why not to add it (and there must be a > reason behind it, and no mail which is 2 years old, or explaining what > the device is, again it got explained what's required from you) > > seems like your response is based on that misunderstood sentence, > sorry for not beeing clear enough. > > Markus Hi Markus, fine chap, Please cool down... I guess I understood Manu's response: a. He just changed his priorities to pick up an old project that seemed to have died, but did not die at all - this project is called cx878 project, and it is the most radical approach that I ever have seen - trying to make all BT8xx drivers independent from bttv, which is not horrible, but only consequent, necessary, and good and fine. Please see my previous mails on that issue. Just read the ML to get the appropriate link and please get yourself in it to help developping it. I swear it is the right path, although I am still missing the avoidance of dvb-pll.c. A closer look into that module will quite easily tell you that there aren't any BT8xx based PCI cards needing that module except the ones needing the lgdt330x frontend driver, which is maintained by Mike Krufky. So for all other cards treated by the dvb-bt8xx backend this module is nothing but heavily obsolete and nonsense, if not to say: RAM-Wasting. b. In so far, Manu's statements do not base on any mail that is 2 years old, but he simply changed his mind, after it was necessarily me personally to build up "the golden bridge" for him, Mike and others as well. c. I am deeply thankful for your diplomatic behaviour involving Trent, as this brought up Manu to react in the end instead of crawling back into his snail house. d. But please let us establish peace among each other now, because without peace we will not be able to continue the whole thing... Hi Trent, I want to thank you for all your efforts - as they at least work for my deep satisfaction, but they may not work for other people as well for simply technical reasons (example: treating dst and dst_ca as one simple case does no good at all, does it?), but our primadonna Manuel Abraham simply follows another far more radical path - to get the whole thing independent from bttv, which is the RIGHT path. Your invested energies weren't wasted at all, but they only approach "plan a" while "plan b" goes much more further than "plan a." It is as simple as that. And, as I stated already, I am open for both plans - and if the more radical one gains more mercy I will not disagree, but simply follow it and trying my best to improve it. Hi Mauro, I would deeply appreciate you to pull my "proposal" for the Kconfig in the frontends section as at least the semantic problem gotta be resolved (SPO instead of SO -
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 3 May 2007 17:59:18 +0200 Von: "Markus Rechberger" <[EMAIL PROTECTED]> An: "Manu Abraham" <[EMAIL PROTECTED]> CC: "Uwe Bugla" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) > On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > Uwe Bugla wrote: > > > > > Hi Manu, > > > > > > But it would be an acceptable compromise FOR NOW, wouldn't it? > > > > > > The reason is i do not wish to make changes to it, till i can fix it. It > > is indeed hard to fix things that support a lot of devices, with > > different issues. There are enough of issues in there. > > > > You can look at all those frontend not found issues on the DVB ML. > > > > The people who make all these noise, do nothing but just play politics. > > Just do a search on the linux-dvb ML at gmane.org. You can easily find > them. > > > > Manu, > > to me it looks like your attitude is not acceptable here, I sent > several mails already which you just use to ignore. > If you don't change that attitude immediatelly I'd really wish to get > you banned of this community until you're open for discussions. > > http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html > > there's a bugreport and you fully ignore it, and you blame it on the > "politicians" here, telling me that there are mails out there > somewhere shows that you're not interested in getting forward. > > I'm waiting for your response here. > > Markus Hey Markus, fine chap: Please cool down! I just downloaded this cx878 thing which will beat a couple of flies with one attack once it is finished. It will be more stable than every preceding driver, it will revolutionize RAM usage extraordinarily, and it will solve all outstanding technical problems involved in the current DST driver concept, if I did understand Manu right, which is different sometimes, but, as it seems, not impossible. So he just changed his priorities, and if this thing is finished we all will be winning a lot in the end I guess... So please at least try to get yourself involved into that project, even if there are outstanding human drawbacks - its hard with him, I know, but it is not impossible at all. And the cx878 project is worth to engage oneself in for a thousands of very good reasons - just believe me, as I have already done a lot of testing work on it. It's fine, and it will revolutionize the whole bt8xx driver concept. So if there are many many people helping to finish it, that will be the best thing ever seen... And as far Manu is concerned: he is a primadonna, as I am. Primadonnas are real extraordinary people, you know. So please do not beat him or treat him like this. Yours sincerely Uwe Peace, brother! > > > > Waiting for your link meanwhile to download that hopeful project... > > > > > http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 > > > > > -- > Markus Rechberger -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:48:50 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) > Uwe Bugla wrote: > > > Hi Manu, > > > > But it would be an acceptable compromise FOR NOW, wouldn't it? > > > The reason is i do not wish to make changes to it, till i can fix it. It > is indeed hard to fix things that support a lot of devices, with > different issues. There are enough of issues in there. > > You can look at all those frontend not found issues on the DVB ML. > > The people who make all these noise, do nothing but just play politics. > Just do a search on the linux-dvb ML at gmane.org. You can easily find > them. > > > Waiting for your link meanwhile to download that hopeful project... > > http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 Sorry Manu, incorrect link! Why? If you download the thing as tar.bz2 you get a zero file down. However, if you download the thing as tar.gz you will succeed in getting it. I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned. I am really looking forward to see this fantastic thing finished It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others... So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see. OKIDOK so far? Uwe -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:15:32 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Mauro Carvalho Chehab <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], Trent Piepho <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) > Mauro Carvalho Chehab wrote: > > Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: > >> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > >>> However, when dst is selected, I got those errors: > >> When I made this patch I was basing it off a patch I made around 9 > months > >> ago. I thought since that one was ok, this would be ok too, and in my > >> hurry to get it done I've clearly put too little effort into checking > it, > >> and I'm sorry to have wasted your time. > >> > >> I promise, this time it's right! > >> http://linuxtv.org/hg/~tap/dst-new > > > > Confirmed. Now the patch is properly working. My tests were done with a > > board with DST. Those are the results: > > > > 1) when DST is unselected, on a board with DST, it will print the errors > > indicating that the Kconfig items were not selected: > > > > DVB: registering new adapter (bttv0). > > DVB: Unable to find symbol dst_attach() > > frontend_init: Could not find a Twinhan DST. > > dvb-bt8xx: A frontend driver was not found for device 109e/0878 > subsystem fbfb/f800 > > > > The only issue is the wrong printk msg, stating that a "frontend driver" > > were not found. As this issue also happens with the current driver, due > > the usage of dvb_attach() macro, I don't see any regressions. > > > > It would be nice, however, to have a patch making dvb_attach more > > generic, by e.g. having a variant that allows passing another message. > > > > Trying to run dvb programs like scan and kaffeine will properly fail. > > > > 2) With DST selected, the driver works properly. > > > > The changes also solved the issue of removing the dst drivers. Before > > the patch, sometimes it is required to force removal of dst module with > > the '-f' flag, since the module count were wrong. > > > > --- > > > > I'll risk to make a briefing of the technical points: > > > > > > Current issues: > > 1) allow deselecting DST/DST_CA support, since this is not needed by > > some supported boards; > > 2) sometimes, module removal don't work with dst, since usage count > > becomes wrong; > > 3) if dst or dst_ca is not properly loaded, the printk message wrongly > > indicates that "A frontend driver was not found" > > > > The Trent's original patch were written on Aug, 2006 (*). The current > > version fixes (1) and (2). It doesn't touch on (3). There aren't any > > other patches properly fixing (1) and (2). > > > > There's an argument against the prototype changes on dst_attach and > > dst_ca_attach since they aren't frontend. > > > > > > (*) Notice: I can't remember why the patches were not applied on that > > time. I think somebody nacked they, although I didn't found any record > > about the patch on my mailbox. > > > > About the usage of frontend support for a non-frontend module, I really > > can't see any issues at the current implementation, since even before > > the patch, all DST initialization are done by a routine called > > "frontend_init()". > > *Wrong*. Frontend Init sends a command to the whole system to > initialize the frontend, Not initialize the DST > Whatever frontend naming conventions are in there are a relic from > Andrew's FE_REFACTORING changesets. > > Even dst not being a frontend, the initialization > > gets the result of the attachment process, using it as a "frontend": > > > > state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); > > > > state->config = _config; > > state->i2c = card->i2c_adapter; > > state->bt = card->bt; > > state->dst_ca = NULL; > > > > dvb_attach(dst_attach, state, >dvb_adapter); > > > > card->fe = >frontend; > > > > (comments and error checks removed to make code cleaner) > > > > The patch basically moved state initialization to dst_attach. The above > > code, after the patch is: > > > > card->fe = dvb_attach(dst_attach, _config, card->bt, > card->i2c_adapter); > > > > So, I didn't noticed any regressions by running the modified driver nor > > I couldn't identify any regressions by inspecting the source code. > > > > The end result seems also cleaner and easier to understand, preserving > > all characteristics of the original code. Also, it uses dvb_attach the > > same way as the other dvb helper modules. > > > > If later any changes will be needed to allow using DST on different > > configurations, future patches probably will need to move dst > > initialization to other places, and use different callbacks for it, > > altering the above initialization. I can't see why those changes would > > possibly avoid any further changes at the driver. > > >
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 18:44:36 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) > Uwe Bugla wrote: > > > On the technical layer I noticed that I heard some Pinnacle relais click > during testing, but there were some i2c_bus symbols missing during > compilation. So I guess those missing symbols are responsible for getting > neither > picture nor sound. > > Can you send your compile warnings ? I couldn't find the same in my > mailbox any report on the same. Maybe my mail filter did something. I can certainly send compile warnings and dmesg and whatever you need. But at first I need another link WHERE I can download the actual cx878 code. Is it thaddathil.net or where the hell has it gone? Just send me one link please, otherwise I do not have any chance to help you, OK? > > > A. If you are really interested I can send you my basic puzzle parts in > short, opening a new thread on this issue. Just give me a short response if > you are interested. > > > > B. If you want to continue the cx878 project please drop me a short note > where I can download it to test and enlarge it with my own ideas as good > as I can. > > > > Must not be immediately (no sweat please), but I am looking forward to > receive a response from you. > > > > What i would like to do is like this: Have the current state frozen as > it is, such that there is a fallback case (The dst is quite fragile and > change at some place would break another. ie, what looks good for one > DST variant is bad for the other). Work on a new tree (CX878) and > migrate stuff to it. Remove the old one, once things are done. > > I wouldn't want to mess up the current working situation and hence. Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? So please don't turn your back on it, even if it may be incomplete for your needs. Just add your SOB and then focus on cx878 with full power, OK? Anything else would be terrible in pschological terms, you know? Just think about Trent, Markus, me, so many others, you know. Do I expect too much? Hope I do not! Plus: If I should help you it would be a pleasure for me if you could offer an acceptable time window that fulfills the following aims: a. not to exhaust or threaten or bug you or nerve you (noone wants that, you know) b. give me and others a feeling for when things of whatever issue are done and resolved, you know. So at least for me it's very hard to continue if the whole thing looks like a never ending story, you know? So please give us a chance. And please do better this time. Just learn and develop, you know. And be more transparent and eloquent this time, but do not crawl back into a snail house, OK? Waiting for your link meanwhile to download that hopeful project... CCing some other persons who are perhaps interested in this Yours sincerely Uwe -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 02 May 2007 20:45:58 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) > Uwe Bugla wrote: > > Original-Nachricht > > Datum: Wed, 02 May 2007 17:30:32 +0400 > > Von: Manu Abraham <[EMAIL PROTECTED]> > > An: Trent Piepho <[EMAIL PROTECTED]> > > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list > , [EMAIL PROTECTED], Jan Engelhardt > <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED], Linux DVB <[EMAIL PROTECTED]> > > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: > Critical points about ...) > > > >> Trent Piepho wrote: > >>> On Tue, 1 May 2007, Simon Arlott wrote: > >>>> On 30/04/07 22:17, Markus Rechberger wrote: > >>>>> From my side I do not see any problem with that patch, if someone > else > >>>>> has a problem with it please state out the reason. > >>>> I have no problem with the patch since it has nothing to do with my > DVB > >>>> card but you're only encouraging Uwe to be abusive since it seems to > >>>> help get him what he wants: > >>> I've been aware of the problem with dst not fully using the dvb > >> customization > >>> systems(*) for a long time. It came up when dvb_attach() et al were > >> first > >>> being integrated, well before any rejected patches or strongly worded > >> emails > >>> or whatever from certain people that I'm aware of. > >>> > >> Well, your understanding of the device is quite limited and hence your > >> comments and patches. > >> > >> The DST as it refers to is an embedded system a x86 Compatible RISC > core > >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's > own > >> IO and 2 DMA channels. What we have is a PQFP device > >> > >> This is the case in most cases. On some cheaper cards the embedded > >> system is replaced by an 8 bit host microcontroller, to cut down costs > >> where all the features are not required for a specific model > >> > >> Additionally this embedded system has a fast shovelling engine for the > >> MPEG2 TS routing in between the > >> This embedded system is connected to an actual > >> (1) DVB frontend [2] > >> (2) DVB CA interface [3] > >> (3) Analog tuner > >> (4) Audio interfaces > >> > >> These features are not the characteristics of a DVB Frontend. Here > there > >> is a DVB frontend like the normal ones which is hidden behind another > >> pseudo bridge (So you don't have *any* access to the frontend at large) > >> > >> It is not necessary that *all* the dst cards (there are around ~15 > >> different variants of the same) do have the very same feature set. > >> > >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In > >> fact it is a combo driver supporting the entire devices using a common > >> command set > >> > >> In such a case it has more characteristics of the PCI bridge and in > fact > >> heavily tied to it and has it's own advantages. > >> > >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, > and > >> since > >>> I already know about the issues here, I felt I should post a patch for > >> them > >>> any other reasonable developers who might spend time on this. > >>> > >> I would think that it would be *extremely* rude for a person to send in > >> patches for a device that which you don't understand at all, when it is > >> for limiting the capability of the said device > > > > Hi Manu, > > now if this is your evalution about it all, then let me tell you that I > feel deeply sorry about it. > > > > Fact is: > > Noone ever intended to send in patches limiting the capability of the > said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and > others never did... > > > > Instead of this we all have very different knowledge and understanding > levels, with you obviously being the one with the most elaborate and > sophisticated level. > > > > So please why, instead of marking other people as "rude" whose solutions > you do not appreciate at all, don't you just pick up the p
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 02 May 2007 20:45:58 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) Uwe Bugla wrote: Original-Nachricht Datum: Wed, 02 May 2007 17:30:32 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Trent Piepho [EMAIL PROTECTED] CC: Simon Arlott [EMAIL PROTECTED], Linux Kernel Mailing list linux-kernel@vger.kernel.org, [EMAIL PROTECTED], Jan Engelhardt [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) Trent Piepho wrote: On Tue, 1 May 2007, Simon Arlott wrote: On 30/04/07 22:17, Markus Rechberger wrote: From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: I've been aware of the problem with dst not fully using the dvb customization systems(*) for a long time. It came up when dvb_attach() et al were first being integrated, well before any rejected patches or strongly worded emails or whatever from certain people that I'm aware of. Well, your understanding of the device is quite limited and hence your comments and patches. The DST as it refers to is an embedded system a x86 Compatible RISC core [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own IO and 2 DMA channels. What we have is a PQFP device This is the case in most cases. On some cheaper cards the embedded system is replaced by an 8 bit host microcontroller, to cut down costs where all the features are not required for a specific model Additionally this embedded system has a fast shovelling engine for the MPEG2 TS routing in between the This embedded system is connected to an actual (1) DVB frontend [2] (2) DVB CA interface [3] (3) Analog tuner (4) Audio interfaces These features are not the characteristics of a DVB Frontend. Here there is a DVB frontend like the normal ones which is hidden behind another pseudo bridge (So you don't have *any* access to the frontend at large) It is not necessary that *all* the dst cards (there are around ~15 different variants of the same) do have the very same feature set. It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In fact it is a combo driver supporting the entire devices using a common command set In such a case it has more characteristics of the PCI bridge and in fact heavily tied to it and has it's own advantages. I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since I already know about the issues here, I felt I should post a patch for them any other reasonable developers who might spend time on this. I would think that it would be *extremely* rude for a person to send in patches for a device that which you don't understand at all, when it is for limiting the capability of the said device Hi Manu, now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. Fact is: Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. So please why, instead of marking other people as rude whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... And this would conform to practising the synergetic principle, wouldn't it? Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do). Above that: 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality. 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 18:44:36 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) Uwe Bugla wrote: On the technical layer I noticed that I heard some Pinnacle relais click during testing, but there were some i2c_bus symbols missing during compilation. So I guess those missing symbols are responsible for getting neither picture nor sound. Can you send your compile warnings ? I couldn't find the same in my mailbox any report on the same. Maybe my mail filter did something. I can certainly send compile warnings and dmesg and whatever you need. But at first I need another link WHERE I can download the actual cx878 code. Is it thaddathil.net or where the hell has it gone? Just send me one link please, otherwise I do not have any chance to help you, OK? A. If you are really interested I can send you my basic puzzle parts in short, opening a new thread on this issue. Just give me a short response if you are interested. B. If you want to continue the cx878 project please drop me a short note where I can download it to test and enlarge it with my own ideas as good as I can. Must not be immediately (no sweat please), but I am looking forward to receive a response from you. What i would like to do is like this: Have the current state frozen as it is, such that there is a fallback case (The dst is quite fragile and change at some place would break another. ie, what looks good for one DST variant is bad for the other). Work on a new tree (CX878) and migrate stuff to it. Remove the old one, once things are done. I wouldn't want to mess up the current working situation and hence. Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? So please don't turn your back on it, even if it may be incomplete for your needs. Just add your SOB and then focus on cx878 with full power, OK? Anything else would be terrible in pschological terms, you know? Just think about Trent, Markus, me, so many others, you know. Do I expect too much? Hope I do not! Plus: If I should help you it would be a pleasure for me if you could offer an acceptable time window that fulfills the following aims: a. not to exhaust or threaten or bug you or nerve you (noone wants that, you know) b. give me and others a feeling for when things of whatever issue are done and resolved, you know. So at least for me it's very hard to continue if the whole thing looks like a never ending story, you know? So please give us a chance. And please do better this time. Just learn and develop, you know. And be more transparent and eloquent this time, but do not crawl back into a snail house, OK? Waiting for your link meanwhile to download that hopeful project... CCing some other persons who are perhaps interested in this Yours sincerely Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:15:32 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Mauro Carvalho Chehab [EMAIL PROTECTED] CC: [EMAIL PROTECTED], Trent Piepho [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) Mauro Carvalho Chehab wrote: Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new Confirmed. Now the patch is properly working. My tests were done with a board with DST. Those are the results: 1) when DST is unselected, on a board with DST, it will print the errors indicating that the Kconfig items were not selected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 The only issue is the wrong printk msg, stating that a frontend driver were not found. As this issue also happens with the current driver, due the usage of dvb_attach() macro, I don't see any regressions. It would be nice, however, to have a patch making dvb_attach more generic, by e.g. having a variant that allows passing another message. Trying to run dvb programs like scan and kaffeine will properly fail. 2) With DST selected, the driver works properly. The changes also solved the issue of removing the dst drivers. Before the patch, sometimes it is required to force removal of dst module with the '-f' flag, since the module count were wrong. --- I'll risk to make a briefing of the technical points: SUMMARY Current issues: 1) allow deselecting DST/DST_CA support, since this is not needed by some supported boards; 2) sometimes, module removal don't work with dst, since usage count becomes wrong; 3) if dst or dst_ca is not properly loaded, the printk message wrongly indicates that A frontend driver was not found The Trent's original patch were written on Aug, 2006 (*). The current version fixes (1) and (2). It doesn't touch on (3). There aren't any other patches properly fixing (1) and (2). There's an argument against the prototype changes on dst_attach and dst_ca_attach since they aren't frontend. /SUMMARY (*) Notice: I can't remember why the patches were not applied on that time. I think somebody nacked they, although I didn't found any record about the patch on my mailbox. About the usage of frontend support for a non-frontend module, I really can't see any issues at the current implementation, since even before the patch, all DST initialization are done by a routine called frontend_init(). *Wrong*. Frontend Init sends a command to the whole system to initialize the frontend, Not initialize the DST Whatever frontend naming conventions are in there are a relic from Andrew's FE_REFACTORING changesets. Even dst not being a frontend, the initialization gets the result of the attachment process, using it as a frontend: state = kmalloc(sizeof (struct dst_state), GFP_KERNEL); state-config = dst_config; state-i2c = card-i2c_adapter; state-bt = card-bt; state-dst_ca = NULL; dvb_attach(dst_attach, state, card-dvb_adapter); card-fe = state-frontend; (comments and error checks removed to make code cleaner) The patch basically moved state initialization to dst_attach. The above code, after the patch is: card-fe = dvb_attach(dst_attach, dst_config, card-bt, card-i2c_adapter); So, I didn't noticed any regressions by running the modified driver nor I couldn't identify any regressions by inspecting the source code. The end result seems also cleaner and easier to understand, preserving all characteristics of the original code. Also, it uses dvb_attach the same way as the other dvb helper modules. If later any changes will be needed to allow using DST on different configurations, future patches probably will need to move dst initialization to other places, and use different callbacks for it, altering the above initialization. I can't see why those changes would possibly avoid any further changes at the driver. That's said, I intend to commit the two patches, fixing the current issues, at this weekend. I did explain my stand in a previous mail. NACK Technically may be OK, psychologically this decision is
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 03 May 2007 19:48:50 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical pointsabout ...) Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 Sorry Manu, incorrect link! Why? If you download the thing as tar.bz2 you get a zero file down. However, if you download the thing as tar.gz you will succeed in getting it. I'll sit down this evening, try to make changes to imply it into the actual mercurial tree, produce necessary patches and give you a bug report as far as the compilation errors are concerned. I am really looking forward to see this fantastic thing finished It's worth it for a thousands of very good reasons, not only RAM optimization, but also stability and many many others... So gimme some time, and perhaps please supply a tar.bz2 version if you can, or fix the download error (zero file) if there is any other reason that I cannot see. OKIDOK so far? Uwe -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Thu, 3 May 2007 17:59:18 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Manu Abraham [EMAIL PROTECTED] CC: Uwe Bugla [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. I'm waiting for your response here. Markus Hey Markus, fine chap: Please cool down! I just downloaded this cx878 thing which will beat a couple of flies with one attack once it is finished. It will be more stable than every preceding driver, it will revolutionize RAM usage extraordinarily, and it will solve all outstanding technical problems involved in the current DST driver concept, if I did understand Manu right, which is different sometimes, but, as it seems, not impossible. So he just changed his priorities, and if this thing is finished we all will be winning a lot in the end I guess... So please at least try to get yourself involved into that project, even if there are outstanding human drawbacks - its hard with him, I know, but it is not impossible at all. And the cx878 project is worth to engage oneself in for a thousands of very good reasons - just believe me, as I have already done a lot of testing work on it. It's fine, and it will revolutionize the whole bt8xx driver concept. So if there are many many people helping to finish it, that will be the best thing ever seen... And as far Manu is concerned: he is a primadonna, as I am. Primadonnas are real extraordinary people, you know. So please do not beat him or treat him like this. Yours sincerely Uwe Peace, brother! Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 -- Markus Rechberger -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Fri, 4 May 2007 00:06:51 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Manu Abraham [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: Enough. Let's stop arguing non technical issues. If either one of you have any technical argue against the Trent's patches, please point where the fix is wrong. Otherwise, if you wish, you may send an acked-by agreeing with the fix. Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer I've seen that too often already, now we could point to a mail someone sent to Uwe regarding maintainership. FYI, I have never written to Uwe regarding any sort of maintainership. You seem to be quite up with an overdose of drugs I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from my side to Uwe, none of which has a topic whatsoever you say. Only the first mail was a private mail and that is CC'd to Johannes as well. Firstly you seem to play politics by getting Uwe to flame me, then when it backfired, you are trying to play tricks with the rest of the community as well, by spreading nonsense statements. I sent several comments to Uwe to stop flaming, Trent was in the CC sometimes I never wrote that he should flame on anyone. I can simply forward you all mails I sent to Uwe there's not one bad mail. My point is moreover to get that issue sorted out by either accepting his proposal or stating out why not to add it (and there must be a reason behind it, and no mail which is 2 years old, or explaining what the device is, again it got explained what's required from you) seems like your response is based on that misunderstood sentence, sorry for not beeing clear enough. Markus Hi Markus, fine chap, Please cool down... I guess I understood Manu's response: a. He just changed his priorities to pick up an old project that seemed to have died, but did not die at all - this project is called cx878 project, and it is the most radical approach that I ever have seen - trying to make all BT8xx drivers independent from bttv, which is not horrible, but only consequent, necessary, and good and fine. Please see my previous mails on that issue. Just read the ML to get the appropriate link and please get yourself in it to help developping it. I swear it is the right path, although I am still missing the avoidance of dvb-pll.c. A closer look into that module will quite easily tell you that there aren't any BT8xx based PCI cards needing that module except the ones needing the lgdt330x frontend driver, which is maintained by Mike Krufky. So for all other cards treated by the dvb-bt8xx backend this module is nothing but heavily obsolete and nonsense, if not to say: RAM-Wasting. b. In so far, Manu's statements do not base on any mail that is 2 years old, but he simply changed his mind, after it was necessarily me personally to build up the golden bridge for him, Mike and others as well. c. I am deeply thankful for your diplomatic behaviour involving Trent, as this brought up Manu to react in the end instead of crawling back into his snail house. d. But please let us establish peace among each other now, because without peace we will not be able to continue the whole thing... Hi Trent, I want to thank you for all your efforts - as they at least work for my deep satisfaction, but they may not work for other people as well for simply technical reasons (example: treating dst and dst_ca as one simple case does no good at all, does it?), but our primadonna Manuel Abraham simply follows another far more radical path - to get the whole thing independent from bttv, which is the RIGHT path. Your invested energies weren't wasted at all, but they only approach plan a while plan b goes much more further than plan a. It is as simple as that. And, as I stated already, I am open for both plans - and if the more radical one gains more mercy I will not disagree, but simply follow it and trying my best to improve it. Hi Mauro, I would deeply appreciate you to pull my proposal for the Kconfig in the frontends section as at least the semantic problem gotta be resolved (SPO instead of SO - whoever wrote this). The question what card needs dvb-pll.c does not stay open so far - I just involved some fact about what card does really need it
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Fri, 04 May 2007 02:31:49 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) Markus Rechberger wrote: I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. I am replying to this mail, just because someone's spreading lies all around. On the mentioned thread, what i wrote (and that was the only mail from my side): There is a saying: He who lives by the sword, dies by the sword. Hi Manu, The saying that you stated is a very christian one. I perhaps should state that I am 47 years old now, raised in in utmost reactionary region called Bavaria (Western Germany), and also raised by parents of Russian / Polonian origin who shared the Nazi regime with the usual I-do-not-want-to-talk-about-it-and-I-do-not-want-to-feel-responsible-about-it -behaviour. And I am very much not only interested in german post-war history, but I simply love to write provocative letters or mails to make my conviction utmost clear that all this capitalist bullshit around us should vanish and shrink and be overcome some day. Basic christian ideals are very close to basic marxist ideas. The one who never does perceive that is a real poor human being in my eyes, if not to say: a complete idiot or a system-conforming hypocrite. BUT: I in fact do not read this saying for the first time: In my personal experience (feel very sorry about it, but it's true) it has always truthfully been an excuse for persons being strongly limited on what I would call utmost primitive instincts like greed or rapacity (i. e. the utmost perfect sounding would-like-to-capitalists, if not to say: the perfect slaves or: the perfect counterrevolutionaries or strike-breakers, if not to say: the utmost perfect asscreepers). Please forgive me for that statement, but I am simply stating my personal experiences very truthfully, without playing any politics, but just telling you my personal truth or the sum of all my personal life experience unfortunately bound to that. And if there is discussion needed on that we should do it private or anyway on some other thread, but definitely not on this one. Hints to help you to understand the difference: 1. There is a GPL license written by Richard Stallman whose origin I do not know: Its essence is the philosophy to share and to be highly transparent as far as information level is concerned. 2. There is a saying by Linus in which he states the best choice he ever did was conforming his work to the terms of Richard Stallman, the GPL. 3. Wikipedia says that Linus's father was no christian at all, but simply a communist. See, Manu, there are deeply primitive instinct-driven hypocrites around like hell, but there are also truthful human beings around. But: The Internet does not provide a platform to find out who is who and what is what. The Internet may be necessary, but in the end it's just a drag, isn't it? Sincerely Uwe Original Message Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Date: Tue, 01 May 2007 04:19:41 +0400 From: Manu Abraham [EMAIL PROTECTED] To: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 02 May 2007 17:30:32 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Trent Piepho <[EMAIL PROTECTED]> CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list , [EMAIL PROTECTED], Jan Engelhardt <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB <[EMAIL PROTECTED]> Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) > Trent Piepho wrote: > > On Tue, 1 May 2007, Simon Arlott wrote: > >> On 30/04/07 22:17, Markus Rechberger wrote: > >>> From my side I do not see any problem with that patch, if someone else > >>> has a problem with it please state out the reason. > >> I have no problem with the patch since it has nothing to do with my DVB > >> card but you're only encouraging Uwe to be abusive since it seems to > >> help get him what he wants: > > > > I've been aware of the problem with dst not fully using the dvb > customization > > systems(*) for a long time. It came up when dvb_attach() et al were > first > > being integrated, well before any rejected patches or strongly worded > emails > > or whatever from certain people that I'm aware of. > > > > Well, your understanding of the device is quite limited and hence your > comments and patches. > > The DST as it refers to is an embedded system a x86 Compatible RISC core > [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own > IO and 2 DMA channels. What we have is a PQFP device > > This is the case in most cases. On some cheaper cards the embedded > system is replaced by an 8 bit host microcontroller, to cut down costs > where all the features are not required for a specific model > > Additionally this embedded system has a fast shovelling engine for the > MPEG2 TS routing in between the > This embedded system is connected to an actual > (1) DVB frontend [2] > (2) DVB CA interface [3] > (3) Analog tuner > (4) Audio interfaces > > These features are not the characteristics of a DVB Frontend. Here there > is a DVB frontend like the normal ones which is hidden behind another > pseudo bridge (So you don't have *any* access to the frontend at large) > > It is not necessary that *all* the dst cards (there are around ~15 > different variants of the same) do have the very same feature set. > > It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In > fact it is a combo driver supporting the entire devices using a common > command set > > In such a case it has more characteristics of the PCI bridge and in fact > heavily tied to it and has it's own advantages. > > > I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and > since > > I already know about the issues here, I felt I should post a patch for > them > > any other reasonable developers who might spend time on this. > > > > I would think that it would be *extremely* rude for a person to send in > patches for a device that which you don't understand at all, when it is > for limiting the capability of the said device Hi Manu, now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. Fact is: Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... And this would conform to practising the synergetic principle, wouldn't it? Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do). Above that: 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality. 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter. 3. When I wrote patches since then I never gave up until there weren't any a. fuzz factors b. rejections
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 2 May 2007 04:10:03 -0700 (PDT) Von: Trent Piepho <[EMAIL PROTECTED]> An: Mauro Carvalho Chehab <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham <[EMAIL PROTECTED]> Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > Em Ter, 2007-05-01 Ã s 16:16 -0700, Trent Piepho escreveu: > > > On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: > > > > With this configuration, dvb-bt8xx hangs during initialization, > > > > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx > > > > never returns). > > > > > > Stupid typo in the first patch, a != should have been ==. > > > > > > Fixed: > > > http://linuxtv.org/hg/~tap/dst-new > > > > With the changes, the dst unselection worked. > > > > Those are the logs with dst unselected: > > > > DVB: registering new adapter (bttv0). > > DVB: Unable to find symbol dst_attach() > > frontend_init: Could not find a Twinhan DST. > > dvb-bt8xx: A frontend driver was not found for device 109e/0878 > subsystem fbfb/f800 > > This is the dvb_attach() "not found" message. You should see this same > message if you leave dst selected and then just delete the dst modules > before > loading dvb-bt8xx. > > If you turn dvb_attach off, you should see a different "dst support was > disabled" message (and no crash!). > > > However, when dst is selected, I got those errors: > > When I made this patch I was basing it off a patch I made around 9 months > ago. I thought since that one was ok, this would be ok too, and in my > hurry to get it done I've clearly put too little effort into checking it, > and I'm sorry to have wasted your time. > > I promise, this time it's right! > http://linuxtv.org/hg/~tap/dst-new The DST card with CA slot and the DST card without CA slot are two different cases. Like the Pinnacle PCTV SAT with CI extension and the Pinnacle PCTV SAT without CI extension. In so far my questions are: Shouldn't there be two cases for deselecting DST modules? At least my basic approach tried to distinct those two cases. In how far is it enough or technically sufficient to treat those two cases as one? And, as already mentioned: At least in all of those 4 cases no dvb-pll module isn't needed at all - someone simply forgot to add some lines for the exception handling in dvb-bt8xx to get rid of dvb-pll.c if there is no lgdt330x frontend needed (read: if there is no Fusion HDTV Lite card in the machine at all). If this small case is being fixed you simply can expand the deselection of dvb-pll.c on all cards treated in backend module dvb-bt8xx.c. Uwe > > ___ > linux-dvb mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 2 May 2007 04:10:03 -0700 (PDT) Von: Trent Piepho [EMAIL PROTECTED] An: Mauro Carvalho Chehab [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Criticalpoints about ...) On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: Em Ter, 2007-05-01 Ã s 16:16 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: With this configuration, dvb-bt8xx hangs during initialization, generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new With the changes, the dst unselection worked. Those are the logs with dst unselected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 This is the dvb_attach() not found message. You should see this same message if you leave dst selected and then just delete the dst modules before loading dvb-bt8xx. If you turn dvb_attach off, you should see a different dst support was disabled message (and no crash!). However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new The DST card with CA slot and the DST card without CA slot are two different cases. Like the Pinnacle PCTV SAT with CI extension and the Pinnacle PCTV SAT without CI extension. In so far my questions are: Shouldn't there be two cases for deselecting DST modules? At least my basic approach tried to distinct those two cases. In how far is it enough or technically sufficient to treat those two cases as one? And, as already mentioned: At least in all of those 4 cases no dvb-pll module isn't needed at all - someone simply forgot to add some lines for the exception handling in dvb-bt8xx to get rid of dvb-pll.c if there is no lgdt330x frontend needed (read: if there is no Fusion HDTV Lite card in the machine at all). If this small case is being fixed you simply can expand the deselection of dvb-pll.c on all cards treated in backend module dvb-bt8xx.c. Uwe ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Wed, 02 May 2007 17:30:32 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Trent Piepho [EMAIL PROTECTED] CC: Simon Arlott [EMAIL PROTECTED], Linux Kernel Mailing list linux-kernel@vger.kernel.org, [EMAIL PROTECTED], Jan Engelhardt [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) Trent Piepho wrote: On Tue, 1 May 2007, Simon Arlott wrote: On 30/04/07 22:17, Markus Rechberger wrote: From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: I've been aware of the problem with dst not fully using the dvb customization systems(*) for a long time. It came up when dvb_attach() et al were first being integrated, well before any rejected patches or strongly worded emails or whatever from certain people that I'm aware of. Well, your understanding of the device is quite limited and hence your comments and patches. The DST as it refers to is an embedded system a x86 Compatible RISC core [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own IO and 2 DMA channels. What we have is a PQFP device This is the case in most cases. On some cheaper cards the embedded system is replaced by an 8 bit host microcontroller, to cut down costs where all the features are not required for a specific model Additionally this embedded system has a fast shovelling engine for the MPEG2 TS routing in between the This embedded system is connected to an actual (1) DVB frontend [2] (2) DVB CA interface [3] (3) Analog tuner (4) Audio interfaces These features are not the characteristics of a DVB Frontend. Here there is a DVB frontend like the normal ones which is hidden behind another pseudo bridge (So you don't have *any* access to the frontend at large) It is not necessary that *all* the dst cards (there are around ~15 different variants of the same) do have the very same feature set. It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In fact it is a combo driver supporting the entire devices using a common command set In such a case it has more characteristics of the PCI bridge and in fact heavily tied to it and has it's own advantages. I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since I already know about the issues here, I felt I should post a patch for them any other reasonable developers who might spend time on this. I would think that it would be *extremely* rude for a person to send in patches for a device that which you don't understand at all, when it is for limiting the capability of the said device Hi Manu, now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. Fact is: Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. So please why, instead of marking other people as rude whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... And this would conform to practising the synergetic principle, wouldn't it? Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do). Above that: 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality. 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter. 3. When I wrote patches since then I never gave up until there weren't any a. fuzz factors b. rejections anymore. Instead I highly tried to put Andrew's The perfect
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 21:35:44 +0100 Von: Simon Arlott <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > On 01/05/07 20:34, Uwe Bugla wrote: > > Original-Nachricht > > Datum: Tue, 01 May 2007 19:50:38 +0100 > > Von: Simon Arlott <[EMAIL PROTECTED]> > >> On 01/05/07 19:30, Uwe Bugla wrote: > >>> > >> If you would avoid making inflammatory comments, the people who are > trying > >> to > >> help you will be more inclined to fix the problems that these patches > DO > >> cause > >> so they can be added. > >> > >> A while ago, you went on and on about your broken floppy drive and how > >> people > >> shouldn't do things that break other systems - even if they have no > idea > >> that > >> was happening - yet here you are now demanding people do the same > thing. > > > > WRONG! > > I offered a patch for the broken floppy, but Linus was faster and ripped > the whole section out, so do not even try to misunderstand or quote me out > of context! > > You complained that changes which break your system[1] shouldn't be added > and now rudely demand your desired changes which have been shown to break > others' should be added immediately. I don't believe I misunderstood you > or got the wrong context - it has nothing to do with the related patch. > > [1] http://lkml.org/lkml/2007/2/25/127 > > > > So I say it again: > > The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully > transparent information with them. It's just air bubbles that he is > producing, nothing else! > > It's always and ever the other part that is exposed to offer transparent > info, but never Chehab himself! > > And it's exactly the same thing with Abraham or Krufky! > > > > And does that behaviour conform with democratic terms? NO WAY! > > So there are three mismatches around: Their names are: Abraham, Krufky, > and Chehab! > > You're worse than that reiser4 fanatic, at least he wasn't rude when he > repeated himself over and over and over. I was going to offer to help > you bisect between -git1 and -git2 (it'd be trivial to run the bisect > here and provide patches to test) Well, thank you for that offer in mind, but the git bisect is only necessary for some people needing to know what the reasons for the AMD K7 router Oopses are (speak: what needs to be inserted in vanilla mainline to make it "round" (2.6.21.3, 4, 5,.)). But meanwhile I got three perfect running machines, implying Trent's stuff, implying self-built stuff, and everything built up on 2.6.21-git4), so I can solve my problems on my own. See, if it is almost impossible to build up necessary majorities to get rid of some utmost nasty gatekeepers @linuxtv.org then I can keep my own patch repositories and save lots of energy. Why should I fight against windmills of such an enourmous stupidity like diagnosed around here? No reason for that! Why should I take part in testing the mm-tree? Nothing but waste of time, isn't it?? The technical issues that still need to be fixed plus some creative ideas I sent to [EMAIL PROTECTED] plus to Trent Piepho. If they get this done - excellent! If not - why should I waste nerves? Because of some stupid Abraham or Krufky?? Or the intransparence of Mr. Chehab's air bubbles?? Why should I?? snip _ Uwe (Rest blather cut off) > Simon Arlott -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 19:50:38 +0100 Von: Simon Arlott <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > On 01/05/07 19:30, Uwe Bugla wrote: > > > > If you would avoid making inflammatory comments, the people who are trying > to > help you will be more inclined to fix the problems that these patches DO > cause > so they can be added. > > A while ago, you went on and on about your broken floppy drive and how > people > shouldn't do things that break other systems - even if they have no idea > that > was happening - yet here you are now demanding people do the same thing. WRONG! I offered a patch for the broken floppy, but Linus was faster and ripped the whole section out, so do not even try to misunderstand or quote me out of context! So I say it again: The theses Mr. Chehab invents NOT TO DO SOMETHING do never carry fully transparent information with them. It's just air bubbles that he is producing, nothing else! It's always and ever the other part that is exposed to offer transparent info, but never Chehab himself! And it's exactly the same thing with Abraham or Krufky! And does that behaviour conform with democratic terms? NO WAY! So there are three mismatches around: Their names are: Abraham, Krufky, and Chehab! Uwe > > It's easy to maintain your own changes to the kernel until equivalent > changes > are committed - you need to be much more patient, especially when > something is > being done about them. > > -- > Simon Arlott -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 01 May 2007 21:20:01 +0200 Von: e9hack <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...) > Uwe Bugla wrote: > > > > The biggest problem that I had with you in the past weeks is and was > that you never even once offer full transparency when you are building up > theses NOT TO accept patches. > > > > And if it is only the other side (me, Trent, others) to be forced to > offer transparent information BUT NOT YOU YOURSELF > > then this is what I would call a deep anti-democratic behaviour. > > > > You can neither help nor can you solve any problem continuing in that > manner, > > can you? > > > > Happy reflection on your very strange methods, with the hope to do > better in the future! If there is some hope - well, I doubt! > > > > Hi Uwe, > > I would like it if you only post technical topics without any comments to > some person. In your case, the comments are > mostly a personally attacks against someone. If I use google to search for > your name: in the last 5 years, on every > board, forum, ML,.. you had trouble with many people. It was always > because someone wasn't your opinion or someone > didn't do what you seems to expect. Afterwards, you did always start your > attacks and flame war. As a result nobody did > response to you and you was fired from some places. Your problem with some > people from this list isn't a problem of this > people. It's a problem of your own and of your communicative skills. If > you cannot respect sentence #1, please go away > and do never post to this list again. > > Just my two cents.. > > - Hartmut Hartmut, one strategy to establish democratic principles is showing up methods of other people like Abraham and Chehab. If you are not ready to perceive this you're really poor. Uwe -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 18:40:54 +0200
Von: "Uwe Bugla" <[EMAIL PROTECTED]>
An: Mauro Carvalho Chehab <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL
PROTECTED]
Betreff: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
>
> Original-Nachricht
> Datum: Tue, 01 May 2007 11:55:33 -0300
> Von: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> An: Markus Rechberger <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham
> <[EMAIL PROTECTED]>
> Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was:
> Critical points about ...)
>
> > Hi Markus,
> >
> > Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> > > Hi,
> > >
> > > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > > in the end.
> > >
> > >
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
> >
> > The above patch plus the other on
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
> >
> > Implements properly the Uwe's ide.
> >
> > However, I did a test here applying both patches, and de-selecting dst
> > drivers.
> >
> > With this configuration, dvb-bt8xx hangs during initialization,
> > generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> > never returns).
> Hi, please: Could you explain to me why you are turning around the logical
> principle all the time?
>
> Those patches (and my humble ones too of course that gained no attention
> for months) were made for the POSITIVE CASE
> in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT
> VICE VERSA!
>
> So please in how far isn't that fantastic work done by Trent enough?
> So it is very clear that if there are oopses and hangups if such a card
> exists and its drivers are deselected.
> No point at all!
> So please explain me the essence why you use the inversion of the given
> logic to NOT ACK or SIGN this beautiful work.
> I want to see THREE valid arguments for this turnaround illogical
> behaviour please.
>
> Uwe
>
> P. S.: I tested Trent's work and I can ensure that there aren't any Oopses
> at all!
> So your case studies are not only highly invented and strange, but they
> aren't any help either. I really wonder what the hell is going on in your
> brain.
> I really ask myself why you are doing this nerve war, this ping-pong game
> all the time.
> This work is done for the case where there aren't any DST cards inside the
> machine,
> so you cannot just come up, turn everything around, and thus pick up the
> inversion that fits into your strange concept (whatever that may be - noone
> except you
> knows) for blocking that good work.
> So I'd deeply appreciate you to stop this strange hindrance policy. You
> will do nobody any favour with that strange behaviour!
> In my eyes you do not want to help at all - you just want to provoke. And
> if in the end someone insults you you seem to have won.
> But you do not win anything with your strange gestures behind other
> peoples backs, you're instead counterproductive.
>
> And EVEN IF you write this publically you should immediately stop to do
> this behind the author's back - so I CCed Trent Piepho.
> Just to see and show him the bad methods that you are using to qualify
> other people's efforts.
>
> >
> > $ ps ax|grep modprobe
> > 2769 pts/0S 0:00 modprobe dvb_bt8xx
> > 2779 pts/0S+ 0:00 grep --color modprobe
> >
> > $ dmesg
> > DVB: registering new adapter (bttv0).
> > DVB: Unable to find symbol dst_attach()
> > Unable to handle kernel NULL pointer dereference at 02f0
> RIP:
> > {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> > PGD 7cfba067 PUD 7cfc5067 PMD 0
> > Oops: [1] SMP
> > CPU 0
> > Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
> > tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
> > tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
> v4l2_common
> > forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd
> ohci_hcd
> > usbcore reiserfs sd_mod sata_nv libata scsi_mod
> > Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
> > RIP: 0010:[]
> > {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> > RSP: 0018:81007c239e38 EFLAGS: 00010296
> > RAX: 002b RBX: 81007c05a800 RCX:
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 11:55:33 -0300
Von: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
An: Markus Rechberger <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham <[EMAIL
PROTECTED]>
Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
> Hi Markus,
>
> Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
> > Hi,
> >
> > Trent Piepho wrote another patch for it, it just completes Uwe's patch
> > in the end.
> >
> >
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
>
> The above patch plus the other on
> http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
>
> Implements properly the Uwe's ide.
>
> However, I did a test here applying both patches, and de-selecting dst
> drivers.
>
> With this configuration, dvb-bt8xx hangs during initialization,
> generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
> never returns).
Hi, please: Could you explain to me why you are turning around the logical
principle all the time?
Those patches (and my humble ones too of course that gained no attention for
months) were made for the POSITIVE CASE
in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT VICE
VERSA!
So please in how far isn't that fantastic work done by Trent enough?
So it is very clear that if there are oopses and hangups if such a card exists
and its drivers are deselected.
No point at all!
So please explain me the essence why you use the inversion of the given logic
to NOT ACK or SIGN this beautiful work.
I want to see THREE valid arguments for this turnaround illogical behaviour
please.
Uwe
P. S.: I tested Trent's work and I can ensure that there aren't any Oopses at
all!
So your case studies are not only highly invented and strange, but they aren't
any help either. I really wonder what the hell is going on in your brain.
I really ask myself why you are doing this nerve war, this ping-pong game all
the time.
This work is done for the case where there aren't any DST cards inside the
machine,
so you cannot just come up, turn everything around, and thus pick up the
inversion that fits into your strange concept (whatever that may be - noone
except you
knows) for blocking that good work.
So I'd deeply appreciate you to stop this strange hindrance policy. You will do
nobody any favour with that strange behaviour!
In my eyes you do not want to help at all - you just want to provoke. And if in
the end someone insults you you seem to have won.
But you do not win anything with your strange gestures behind other peoples
backs, you're instead counterproductive.
And EVEN IF you write this publically you should immediately stop to do this
behind the author's back - so I CCed Trent Piepho.
Just to see and show him the bad methods that you are using to qualify other
people's efforts.
>
> $ ps ax|grep modprobe
> 2769 pts/0S 0:00 modprobe dvb_bt8xx
> 2779 pts/0S+ 0:00 grep --color modprobe
>
> $ dmesg
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> Unable to handle kernel NULL pointer dereference at 02f0 RIP:
> {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> PGD 7cfba067 PUD 7cfc5067 PMD 0
> Oops: [1] SMP
> CPU 0
> Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
> tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
> tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
> v4l2_common
> forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd
> usbcore reiserfs sd_mod sata_nv libata scsi_mod
> Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
> RIP: 0010:[]
> {:dvb_bt8xx:dvb_bt8xx_probe+3195}
> RSP: 0018:81007c239e38 EFLAGS: 00010296
> RAX: 002b RBX: 81007c05a800 RCX: 0003
> RDX: RSI: 0292 RDI: 803905bc
> RBP: R08: 4c72 R09:
> R10: R11: R12: 81007c19
> R13: 81007c05a8d0 R14: 81007c05ac98 R15: 81007c05abc8
> FS: 2b8b39ddf6f0() GS:80476000()
> knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 02f0 CR3: 7cfc2000 CR4: 06e0
> Process modprobe (pid: 1286, threadinfo 81007c238000, task
> 81007dfd4960)
> Stack: 81007c05acb0 81007c05a870 00717c1e31c0 81007c190198
>81007c19 88261940 88261940
>00518130 8026ce95
> Call Trace: {driver_probe_device+101}
>{__driver_attach+122}
> {__driver_attach+0}
>{bus_for_each_dev+73}
> {bus_add_driver+136}
>{sys_init_module+199}
> {system_call+126}
>
> Code: f6 04 25 f0 02 00 00 20 0f 84 01 ff ff ff e9 7d fd ff ff 66
> RIP
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 1 May 2007 11:00:44 +0200 Von: "Markus Rechberger" <[EMAIL PROTECTED]> An: "Simon Arlott" <[EMAIL PROTECTED]> CC: Manu Abraham <[EMAIL PROTECTED]>, [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Jan Engelhardt <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) > On 5/1/07, Simon Arlott <[EMAIL PROTECTED]> wrote: > > On 30/04/07 22:17, Markus Rechberger wrote: > > > Trent Piepho wrote another patch for it, it just completes Uwe's patch > > > in the end. > > > From my side I do not see any problem with that patch, if someone else > > > has a problem with it please state out the reason. > > > > I have no problem with the patch since it has nothing to do with my DVB > > card but you're only encouraging Uwe to be abusive since it seems to > > help get him what he wants: > > > > On 01/05/07 00:05, Uwe Bugla wrote: > > > Piepho, you are a devil, and your links do not work at all! > > > Uwe > > > > On 01/05/07 00:40, Uwe Bugla wrote: > > > Go to hell, Manuel Abraham, and do not return at all to absolutely no > > thinkable condition at all, and never come back to this place once more > > again > > > Just goto hell, you goddamn deeply asocial miserable sonofabitch!! > > > > > > Uwe > > > > > On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > > >> it's enough, I told him that I'll look at it and try to get some > other > > >> people involved if it really breaks something it should get stated > > >> out; and I'll refuse any further help if he starts to write any more > > >> abusive mail. > > > > It's not working. Patches should still be applied on the basis of what > > they do and how, not why they were made, of course. > > this patch was written by Trent, and it seems like he already had that > idea earlier too. > > I really don't care if that patch goes in or not in the end, there's > just no need to flame around for it. > > The only reason I see is that it's not needed to link it statically > against the bt878 module and there isn't even much work to do. > Uwe's Makefile patch worked as expected, but it wasn't clean/complete > enough that was a reason to not include it. > Now with Trent's patch I don't see that as a valid argument against it > anymore. > And the email from Manu claiming that it generates alot work (which is > btw. 2 years old) doesn't seem to be valid either. > > Markus Thank you, Markus - you are a real fine and straight chap. You should be team leader of this community. BTW: Are my latest attempts sent to you already involved in the latest development state (Read: Is dvb-pll.c deselectable now without breaking support for lgdt330)? I simply stumbled over that lgdt330 binding in module dvb-bt8xx.c, line 641 or so. Anything else I resolved at least from my personal side. A thousands of thanks to you and Trent - well done! > > ___ > linux-dvb mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Tue, 01 May 2007 04:19:41 +0400 Von: Manu Abraham <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and pseudo-authorities > Uwe Bugla wrote: > > > 1. You utmost personally are responsible for 4 ununsable kernels, as far > as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! > > 2. You did not even want to imply to resolve that issue by incarnating > that "community and synergy principle" that linux community needs to exist > at all, but you just perverted it by flaming capable people - > > You mean like this: > Yes I mean like this. But I do not only talk about me. I talk about many many others. Above that you flamed Edgar Toernig with the invented alibi for not signing his contributions (yes I say invented alibi and I mean it exactly that way - in so far the word "gatekeeper" is no invention in this context at all, it's just a very cynical expression that shows a lot of frustration). To get it back to the comprehensive layer: 1. 4 unusable kernels are not just another cavalier's delict, but just a very harsh and deep cut in kernel development history (read: the time space for that breakdown is close to 9 or 10 months). This could have been some three months or less if you weren't the personality that you obviously are representing. 2. Although I tried to tell you a thousand times that I prefer to optimize the existing (read: bttv dependent - even if it may sound senseless to you) concept you continued to pursue a dead born child called cx878. This hopeful project which I would have highly admired if it ever were finished did not only die out of the personal time schedule of a very capable kaffeine developer called Christoph Pfister (who did the main work for it - not you), but it simply died as a consequence of your obviously missing knowledge. Some i2c bus bindings were missing - in so far the mounting of a 2000 meters high mountain was cancelled 50 meters before the top. So what do I mean by optimizing the existing concept? Very simple: Deselectable DST module, deselectable DST_CA module, deselectable dvb-pll module - not more - not less. Now if this very humble concept works, if all this horrible dvb_core_attach stuff and other problems are resolved let's talk about getting rid of all the not necessary bttv dependency nonsense, but never vice versa and never before that. Read: long way, small steps, but no breakdowns. Did I pronounce clear now, Mister Abraham? It can't be that hard to understand this, can it? Uwe > > Original Message > Subject: kernel patch practice in 2.6.13-mm2 > Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) > From: Uwe Bugla <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > > Hi, > if you continue to send or sign mm-patches for Kernel 2.6.13 as a > consequence of a design change I would appreciate you to stop rubbing out > my > name. > You did that in a file called /Documentation/dvb/bt8xx.txt. > My objective is understandable good documentation, even if it may sound > trivial for some developpers minds. I always have in mind that there are > also lots of beginners reading those documents. > As I respect your work I never in my life would even dare to rub out other > coauthors names. > That´s why I appreciate you to respect my name and stop rubbing it out. > > Thanks > Uwe Bugla > > P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of > disrespect. So have a little respect vice versa! > > -- > Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! > Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner > > > --- Original Message > Subject: "synchronization problems" > Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) > From: Uwe Bugla <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > > Hallo Mr. Stezenbach, > > "You breached the protocol by not sending the patches to the maintainer > or linux-dvb list. The result of this was that we had conflicting > changes in CVS. I spent about 10 minutes thinking how I could > merge the two, and then gave up (I had 53 other patches to prepare > and I had little time left to do the job). So I didn't just remove > your name, but all changes which you sent to akpm along with it. > bt8xx.txt in the kernel is now in sync with the version in linuxtv.org > CVS." > > I didn't breach any protocol, nor did I break any unwritten rule or law. I > simply took the advice from Gerd Knor
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
Original-Nachricht Datum: Tue, 01 May 2007 04:19:41 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and pseudo-authorities Uwe Bugla wrote: 1. You utmost personally are responsible for 4 ununsable kernels, as far as bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16! 2. You did not even want to imply to resolve that issue by incarnating that community and synergy principle that linux community needs to exist at all, but you just perverted it by flaming capable people - You mean like this: Yes I mean like this. But I do not only talk about me. I talk about many many others. Above that you flamed Edgar Toernig with the invented alibi for not signing his contributions (yes I say invented alibi and I mean it exactly that way - in so far the word gatekeeper is no invention in this context at all, it's just a very cynical expression that shows a lot of frustration). To get it back to the comprehensive layer: 1. 4 unusable kernels are not just another cavalier's delict, but just a very harsh and deep cut in kernel development history (read: the time space for that breakdown is close to 9 or 10 months). This could have been some three months or less if you weren't the personality that you obviously are representing. 2. Although I tried to tell you a thousand times that I prefer to optimize the existing (read: bttv dependent - even if it may sound senseless to you) concept you continued to pursue a dead born child called cx878. This hopeful project which I would have highly admired if it ever were finished did not only die out of the personal time schedule of a very capable kaffeine developer called Christoph Pfister (who did the main work for it - not you), but it simply died as a consequence of your obviously missing knowledge. Some i2c bus bindings were missing - in so far the mounting of a 2000 meters high mountain was cancelled 50 meters before the top. So what do I mean by optimizing the existing concept? Very simple: Deselectable DST module, deselectable DST_CA module, deselectable dvb-pll module - not more - not less. Now if this very humble concept works, if all this horrible dvb_core_attach stuff and other problems are resolved let's talk about getting rid of all the not necessary bttv dependency nonsense, but never vice versa and never before that. Read: long way, small steps, but no breakdowns. Did I pronounce clear now, Mister Abraham? It can't be that hard to understand this, can it? Uwe Original Message Subject: kernel patch practice in 2.6.13-mm2 Date: Tue, 13 Sep 2005 16:46:35 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, if you continue to send or sign mm-patches for Kernel 2.6.13 as a consequence of a design change I would appreciate you to stop rubbing out my name. You did that in a file called /Documentation/dvb/bt8xx.txt. My objective is understandable good documentation, even if it may sound trivial for some developpers minds. I always have in mind that there are also lots of beginners reading those documents. As I respect your work I never in my life would even dare to rub out other coauthors names. That´s why I appreciate you to respect my name and stop rubbing it out. Thanks Uwe Bugla P. S.: If you f. ex. publish a book I ain´t gonna burn it as a matter of disrespect. So have a little respect vice versa! -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner --- Original Message Subject: synchronization problems Date: Thu, 15 Sep 2005 10:44:38 +0200 (MEST) From: Uwe Bugla [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hallo Mr. Stezenbach, You breached the protocol by not sending the patches to the maintainer or linux-dvb list. The result of this was that we had conflicting changes in CVS. I spent about 10 minutes thinking how I could merge the two, and then gave up (I had 53 other patches to prepare and I had little time left to do the job). So I didn't just remove your name, but all changes which you sent to akpm along with it. bt8xx.txt in the kernel is now in sync with the version in linuxtv.org CVS. I didn't breach any protocol, nor did I break any unwritten rule or law. I simply took the advice from Gerd Knorr that linuxtv maintainers were just moving to another place to the point of time when I sent in my first dvb-bt8xx-patch. So consequently I took the direct way to send it to akpm. Just to be sure it is really being applied without waiting 3, 4 weeks or however long. So if you continue to at least discussing with my person, please
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht Datum: Tue, 1 May 2007 11:00:44 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Simon Arlott [EMAIL PROTECTED] CC: Manu Abraham [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Jan Engelhardt [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...) On 5/1/07, Simon Arlott [EMAIL PROTECTED] wrote: On 30/04/07 22:17, Markus Rechberger wrote: Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: On 01/05/07 00:05, Uwe Bugla wrote: Piepho, you are a devil, and your links do not work at all! Uwe On 01/05/07 00:40, Uwe Bugla wrote: Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again Just goto hell, you goddamn deeply asocial miserable sonofabitch!! Uwe On 4/30/07, Markus Rechberger [EMAIL PROTECTED] wrote: it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. It's not working. Patches should still be applied on the basis of what they do and how, not why they were made, of course. this patch was written by Trent, and it seems like he already had that idea earlier too. I really don't care if that patch goes in or not in the end, there's just no need to flame around for it. The only reason I see is that it's not needed to link it statically against the bt878 module and there isn't even much work to do. Uwe's Makefile patch worked as expected, but it wasn't clean/complete enough that was a reason to not include it. Now with Trent's patch I don't see that as a valid argument against it anymore. And the email from Manu claiming that it generates alot work (which is btw. 2 years old) doesn't seem to be valid either. Markus Thank you, Markus - you are a real fine and straight chap. You should be team leader of this community. BTW: Are my latest attempts sent to you already involved in the latest development state (Read: Is dvb-pll.c deselectable now without breaking support for lgdt330)? I simply stumbled over that lgdt330 binding in module dvb-bt8xx.c, line 641 or so. Anything else I resolved at least from my personal side. A thousands of thanks to you and Trent - well done! ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
Original-Nachricht
Datum: Tue, 01 May 2007 11:55:33 -0300
Von: Mauro Carvalho Chehab [EMAIL PROTECTED]
An: Markus Rechberger [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, Manu Abraham [EMAIL
PROTECTED]
Betreff: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical
points about ...)
Hi Markus,
Em Seg, 2007-04-30 às 23:17 +0200, Markus Rechberger escreveu:
Hi,
Trent Piepho wrote another patch for it, it just completes Uwe's patch
in the end.
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb
The above patch plus the other on
http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=32fb55ac9501;style=gitweb
Implements properly the Uwe's ide.
However, I did a test here applying both patches, and de-selecting dst
drivers.
With this configuration, dvb-bt8xx hangs during initialization,
generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx
never returns).
Hi, please: Could you explain to me why you are turning around the logical
principle all the time?
Those patches (and my humble ones too of course that gained no attention for
months) were made for the POSITIVE CASE
in which it is ENSURED that a DST card DOES NOT EXIST in the machine, NOT VICE
VERSA!
So please in how far isn't that fantastic work done by Trent enough?
So it is very clear that if there are oopses and hangups if such a card exists
and its drivers are deselected.
No point at all!
So please explain me the essence why you use the inversion of the given logic
to NOT ACK or SIGN this beautiful work.
I want to see THREE valid arguments for this turnaround illogical behaviour
please.
Uwe
P. S.: I tested Trent's work and I can ensure that there aren't any Oopses at
all!
So your case studies are not only highly invented and strange, but they aren't
any help either. I really wonder what the hell is going on in your brain.
I really ask myself why you are doing this nerve war, this ping-pong game all
the time.
This work is done for the case where there aren't any DST cards inside the
machine,
so you cannot just come up, turn everything around, and thus pick up the
inversion that fits into your strange concept (whatever that may be - noone
except you
knows) for blocking that good work.
So I'd deeply appreciate you to stop this strange hindrance policy. You will do
nobody any favour with that strange behaviour!
In my eyes you do not want to help at all - you just want to provoke. And if in
the end someone insults you you seem to have won.
But you do not win anything with your strange gestures behind other peoples
backs, you're instead counterproductive.
And EVEN IF you write this publically you should immediately stop to do this
behind the author's back - so I CCed Trent Piepho.
Just to see and show him the bad methods that you are using to qualify other
people's efforts.
$ ps ax|grep modprobe
2769 pts/0S 0:00 modprobe dvb_bt8xx
2779 pts/0S+ 0:00 grep --color modprobe
$ dmesg
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
Unable to handle kernel NULL pointer dereference at 02f0 RIP:
8825f11b{:dvb_bt8xx:dvb_bt8xx_probe+3195}
PGD 7cfba067 PUD 7cfc5067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: dvb_bt8xx dvb_core cx8800 cx88xx bt878 usbhid dvb_pll
tuner bttv video_buf firmware_class ir_common i2c_algo_bit btcx_risc
tveeprom i2c_core pcspkr sn9c102 compat_ioctl32 videodev v4l1_compat
v4l2_common
forcedeth kqemu joydev analog gameport ohci1394 ieee1394 ehci_hcd ohci_hcd
usbcore reiserfs sd_mod sata_nv libata scsi_mod
Pid: 1286, comm: modprobe Tainted: P 2.6.17.4 #1
RIP: 0010:[8825f11b]
8825f11b{:dvb_bt8xx:dvb_bt8xx_probe+3195}
RSP: 0018:81007c239e38 EFLAGS: 00010296
RAX: 002b RBX: 81007c05a800 RCX: 0003
RDX: RSI: 0292 RDI: 803905bc
RBP: R08: 4c72 R09:
R10: R11: R12: 81007c19
R13: 81007c05a8d0 R14: 81007c05ac98 R15: 81007c05abc8
FS: 2b8b39ddf6f0() GS:80476000()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 02f0 CR3: 7cfc2000 CR4: 06e0
Process modprobe (pid: 1286, threadinfo 81007c238000, task
81007dfd4960)
Stack: 81007c05acb0 81007c05a870 00717c1e31c0 81007c190198
81007c19 88261940 88261940
00518130 8026ce95
Call Trace: 8026ce95{driver_probe_device+101}
8026d00a{__driver_attach+122}
8026cf90{__driver_attach+0}
8026c6f9{bus_for_each_dev+73}
8026c2e8{bus_add_driver+136}
80152977{sys_init_module+199}
80109d2a{system_call+126}
Code: f6 04 25 f0
