* Re: [Linux-ia64] Can't boot in SMP with kernel 2.5.50 ia64
From: David Mosberger @ 2002-12-19 20:40 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805616@msgid-missing>
>>>>> On Thu, 19 Dec 2002 08:53:06 +0100 (NFT), Xavier Bru <Xavier.Bru@bull.net> said:
Xavier> Hello,
Xavier> Booting 2.5.50 with David's patch, it seems we can't boot in
Xavier> SMP on an ia64 machine. We get the message: SMP mode
Xavier> deactivated. Problem is due to smp_prepare_cpus() declaring
Xavier> max_cpus as "unsigned int" and testing against the -1 value.
Xavier> Problem was not seen in 2.5.45 because max_cpus was
Xavier> initialized to UINT_MAX.
I think the test in smp_prepare_cpus() is bogus. I changed it to test
just against 0 (as is done in the x86 version of smpboot.c).
--david
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 20:59 UTC (permalink / raw)
To: Eli Carter; +Cc: dank, linux-kernel
In-Reply-To: <3E022E56.30509@inet.com>
> And what about GNATS? What about the others on
> http://www.a-a-p.org/tools_tracking.html ? A number of those address
> the web-based concern. Do any of them answer your other concerns? If
> there are, where do those fail that bugzilla, GNATS, etc. get it right?
Why are you so against somebody sitting down and thinking, "OK, we
need a bug tracking database designed for debugging the Linux
kernel."? I don't understand why you think it's a bad idea to start
over. If my code was rubbish, then it wouldn't get used, and I wasted
my time. Nobody else suffers.
> But I see that starting from scratch is just the way you work:
> http://grabjohn.com/question.php?q=6
Well, since it's me that's offering to write the code, don't I get to
decide how to write it?
Besides, I'm not the only person who thinks it's a good idea to start
over sometimes - Eric Raymond even addresses this point in The
Cathedreal and the Bazaar.
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html
> Well, have fun, good luck, and I do hope you come up with something
> useful and maintainable.
If not, I will admit you were right to the list :-).
John.
^ permalink raw reply
* [PATCH] 2.5.52 n_hdlc.c
From: Paul Fulghum @ 2002-12-19 20:42 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: torvalds@transmeta.com
Make global func/var static to avoid namespace polution
--- linux-2.5.52/drivers/char/n_hdlc.c Sun Dec 15 20:07:51 2002
+++ linux-2.5.52-mg/drivers/char/n_hdlc.c Thu Dec 19 12:01:23 2002
@@ -9,7 +9,7 @@
* Al Longyear <longyear@netcom.com>, Paul Mackerras <Paul.Mackerras@cs.anu.edu.au>
*
* Original release 01/11/99
- * $Id: n_hdlc.c,v 4.2 2002/10/10 14:52:41 paulkf Exp $
+ * $Id: n_hdlc.c,v 4.3 2002/12/19 18:58:56 paulkf Exp $
*
* This code is released under the GNU General Public License (GPL)
*
@@ -78,7 +78,7 @@
*/
#define HDLC_MAGIC 0x239e
-#define HDLC_VERSION "$Revision: 4.2 $"
+#define HDLC_VERSION "$Revision: 4.3 $"
#include <linux/version.h>
#include <linux/config.h>
@@ -171,9 +171,9 @@
/*
* HDLC buffer list manipulation functions
*/
-void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list);
-void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf);
-N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list);
+static void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list);
+static void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf);
+static N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list);
/* Local functions */
@@ -185,10 +185,10 @@
/* debug level can be set by insmod for debugging purposes */
#define DEBUG_LEVEL_INFO 1
-int debuglevel=0;
+static int debuglevel=0;
/* max frame size for memory allocations */
-ssize_t maxframe=4096;
+static ssize_t maxframe=4096;
/* TTY callbacks */
@@ -903,7 +903,7 @@
* Arguments: list pointer to buffer list
* Return Value: None
*/
-void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list)
+static void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list)
{
memset(list,0,sizeof(N_HDLC_BUF_LIST));
spin_lock_init(&list->spinlock);
@@ -920,7 +920,7 @@
*
* Return Value: None
*/
-void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf)
+static void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf)
{
unsigned long flags;
spin_lock_irqsave(&list->spinlock,flags);
@@ -950,7 +950,7 @@
*
* pointer to HDLC buffer if available, otherwise NULL
*/
-N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list)
+static N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list)
{
unsigned long flags;
N_HDLC_BUF *buf;
^ permalink raw reply
* [PATCH] 2.4.20 n_hdlc.c
From: Paul Fulghum @ 2002-12-19 20:41 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: marcelo@conectiva.com.br, alan@lxorguk.ukuu.org.uk
Make global func/var static to avoid namespace polution.
Fix memory leak.
--- linux-2.4.20/drivers/char/n_hdlc.c Mon Feb 25 13:37:57 2002
+++ linux-2.4.20-mg/drivers/char/n_hdlc.c Thu Dec 19 12:01:09 2002
@@ -9,7 +9,7 @@
* Al Longyear <longyear@netcom.com>, Paul Mackerras <Paul.Mackerras@cs.anu.edu.au>
*
* Original release 01/11/99
- * $Id: n_hdlc.c,v 3.3 2001/11/08 16:16:03 paulkf Exp $
+ * $Id: n_hdlc.c,v 3.6 2002/12/19 18:58:56 paulkf Exp $
*
* This code is released under the GNU General Public License (GPL)
*
@@ -78,7 +78,7 @@
*/
#define HDLC_MAGIC 0x239e
-#define HDLC_VERSION "$Revision: 3.3 $"
+#define HDLC_VERSION "$Revision: 3.6 $"
#include <linux/version.h>
#include <linux/config.h>
@@ -172,9 +172,9 @@
/*
* HDLC buffer list manipulation functions
*/
-void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list);
-void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf);
-N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list);
+static void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list);
+static void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf);
+static N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list);
/* Local functions */
@@ -186,10 +186,10 @@
/* debug level can be set by insmod for debugging purposes */
#define DEBUG_LEVEL_INFO 1
-int debuglevel=0;
+static int debuglevel=0;
/* max frame size for memory allocations */
-ssize_t maxframe=4096;
+static ssize_t maxframe=4096;
/* TTY callbacks */
@@ -265,7 +265,8 @@
} else
break;
}
-
+ if (n_hdlc->tbuf)
+ kfree(n_hdlc->tbuf);
kfree(n_hdlc);
} /* end of n_hdlc_release() */
@@ -905,7 +906,7 @@
* Arguments: list pointer to buffer list
* Return Value: None
*/
-void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list)
+static void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list)
{
memset(list,0,sizeof(N_HDLC_BUF_LIST));
spin_lock_init(&list->spinlock);
@@ -922,7 +923,7 @@
*
* Return Value: None
*/
-void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf)
+static void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf)
{
unsigned long flags;
spin_lock_irqsave(&list->spinlock,flags);
@@ -952,7 +953,7 @@
*
* pointer to HDLC buffer if available, otherwise NULL
*/
-N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list)
+static N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list)
{
unsigned long flags;
N_HDLC_BUF *buf;
^ permalink raw reply
* [PATCH] 2.2.23 n_hdlc.c
From: Paul Fulghum @ 2002-12-19 20:39 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org; +Cc: alan@lxorguk.ukuu.org.uk
Make global func/var static to avoid namespace polution
--- linux-2.2.23/drivers/char/n_hdlc.c Fri Nov 2 10:39:06 2001
+++ linux-2.2.23-mg/drivers/char/n_hdlc.c Thu Dec 19 12:00:52 2002
@@ -9,7 +9,7 @@
* Al Longyear <longyear@netcom.com>, Paul Mackerras <Paul.Mackerras@cs.anu.edu.au>
*
* Original release 01/11/99
- * $Id: n_hdlc.c,v 2.3 2001/05/09 14:42:37 paul Exp $
+ * $Id: n_hdlc.c,v 2.4 2002/12/19 18:58:54 paulkf Exp $
*
* This code is released under the GNU General Public License (GPL)
*
@@ -78,7 +78,7 @@
*/
#define HDLC_MAGIC 0x239e
-#define HDLC_VERSION "$Revision: 2.3 $"
+#define HDLC_VERSION "$Revision: 2.4 $"
#include <linux/version.h>
#include <linux/config.h>
@@ -184,9 +184,9 @@
/*
* HDLC buffer list manipulation functions
*/
-void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list);
-void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf);
-N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list);
+static void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list);
+static void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf);
+static N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list);
/* Local functions */
@@ -197,10 +197,10 @@
/* debug level can be set by insmod for debugging purposes */
#define DEBUG_LEVEL_INFO 1
-int debuglevel=0;
+static int debuglevel=0;
/* max frame size for memory allocations */
-ssize_t maxframe=4096;
+static ssize_t maxframe=4096;
/* TTY callbacks */
@@ -921,7 +921,7 @@
* Arguments: list pointer to buffer list
* Return Value: None
*/
-void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list)
+static void n_hdlc_buf_list_init(N_HDLC_BUF_LIST *list)
{
memset(list,0,sizeof(N_HDLC_BUF_LIST));
spin_lock_init(&list->spinlock);
@@ -938,7 +938,7 @@
*
* Return Value: None
*/
-void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf)
+static void n_hdlc_buf_put(N_HDLC_BUF_LIST *list,N_HDLC_BUF *buf)
{
unsigned long flags;
spin_lock_irqsave(&list->spinlock,flags);
@@ -968,7 +968,7 @@
*
* pointer to HDLC buffer if available, otherwise NULL
*/
-N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list)
+static N_HDLC_BUF* n_hdlc_buf_get(N_HDLC_BUF_LIST *list)
{
unsigned long flags;
N_HDLC_BUF *buf;
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 20:38 UTC (permalink / raw)
To: John Bradford; +Cc: dank, linux-kernel
In-Reply-To: <200212192008.gBJK8g7P002563@darkstar.example.net>
John Bradford wrote:
>>Ok, have you looked at other bug tracking programs? Can you find
>>something you can build on? Take a look at this list of issue tracking
>>software:
>>http://www.a-a-p.org/tools_tracking.html
>>It has a lot of possibilities... different combinations of features and
>>implementation languages.
>>
>>Could you perhaps expound a bit on your statement "there is nothing
>>about [bugzilla] that I think [is] right at the moment"?
>
>
> * It uses Javascript in the search forms
> * The search forms are not intuitive to use
> * It's difficult to check that you're not reporting a duplicate bug
> * It's almost all only web-based
> * There is no way that you can track different versions to the extent
> we need to.
>
> The last point is the one that I think is most important.
[snip explanation of version issue]
And what about GNATS? What about the others on
http://www.a-a-p.org/tools_tracking.html ? A number of those address
the web-based concern. Do any of them answer your other concerns? If
there are, where do those fail that bugzilla, GNATS, etc. get it right?
But I see that starting from scratch is just the way you work:
http://grabjohn.com/question.php?q=6
Well, have fun, good luck, and I do hope you come up with something
useful and maintainable.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Randy.Dunlap @ 2002-12-19 20:32 UTC (permalink / raw)
To: Dave Jones; +Cc: John Bradford, linux-kernel
In-Reply-To: <20021219201811.GA7715@suse.de>
[cc list trimmed]
On Thu, 19 Dec 2002, Dave Jones wrote:
| On Thu, Dec 19, 2002 at 07:52:29PM +0000, John Bradford wrote:
| > > I also don't trust things like this where if something goes wrong,
| > > we could lose the bug report.
| > How? I don't see as that is more likely than with Bugzilla.
|
| user submits bug report
| robot rejects it
| user reads rejection, gets confused, gives up.
|
| > Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
|
| Point to one important posting thats been ignored in recent times.
| More likely they weren't ignored, it was just deemed irrelevant,
| unimportant, or lacked information detailing how important the problem
| was.
It can be difficult to tell the difference.
| Besides, this is one area where bugzilla is helping.
| If I ignored/missed an agp related bug report on linux kernel,
| and the same user also filed it in bugzilla, I'll get pestered
| about it automatically later.
|
| > I don't see any way of making Bugzilla do all the things I described
| > originally, specifically the advanced tracking of versions tested.
|
| I still think you're solving a non-problem. Of the 180 or so bugs so
| far, there has been _1_ vendor kernel report. 1 2.4 report. and
| 1 (maybe 2) undecoded oopses (which were subsequently decoded less
| than 24hrs later.
|
| > That could help to find duplicates, which is a big problem when you
| > have 1000+ bugs.
|
| In an ideal world, we'd never have that many open bugs 8-)
| Realistically, I check bugzilla a few times a day, I notice
| when something new has been added. Near the end of each week
| I[*] go through every remaining open bug looking to see if there's
| something additional that can be added / pinging old reporters /
| closing dead bugs. Dupes usually stand out doing this.
| How exactly do you plan to automate dupe detection ?
| You can't even do things like comparing oops dumps, as they
| may have been triggered in different ways,.
|
| Dave
|
| [*] and hopefully, I'm not the only one who does this.
Yes, I go thru them fairly often also, looking for patches or to apply some
patches to close some if possible.
I hope we aren't the only ones...
--
~Randy
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 20:45 UTC (permalink / raw)
To: Eli Carter; +Cc: linux-kernel
In-Reply-To: <3E022B01.2030205@inet.com>
> > In any case, people could take the kernel bug database, and
> > genericify it, much more easily than somebody could tailor an existing
> > bug tracking application to the needs of the kernel, (which is
> > demonstrated by the fact that the developers are not getting Bugzilla
> > reports).
>
> Perhaps, but I'm not convinced that it would be easier to write a kernel
> bug database from scratch than it would be to improve an existing
> project to address the kernel's needs. And _that_ is what we were
> discussing.
Ah, well no wonder we're not agreeing :-), I actually saw the
re-writing from scratch as being easier :-).
Maybe I am just in the minority in that I don't find Bugzilla intuitive.
John.
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Justin Pryzby @ 2002-12-19 20:33 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <2CC936747EA1284DA378A18D730697420158A50E@exchacad.ms.gettysburg.edu>
On Thu, Dec 19, 2002 at 01:53:29PM -0500, Dave Jones wrote:
> On Thu, Dec 19, 2002 at 11:48:16AM -0600, Eli Carter wrote:
> > >Also, we could have a non-web interface, (telnet or gopher to the bug
> > >DB, or control it by E-Mail).
>
> It's an annoyance to me that the current bugzilla we use can only
>
> Its a nice idea, but I think it's a lot of effort to get it right,
> when a human can look at the dump, realise its not decoded, and
I can't say I'm partial to bugzilla either; the reasons above are valid.
I think it could be very useful to have a bugtracking system written by
someone@kernel.org (or at least have someone@kernel.org who is intimitely
familiar with the bugtracking code). The above dislikes of bugzilla are
all fixable, and it may be easier for someone to do it from scratch than
to try to decode someone else's messy code (I wonder if there is a
bugzilla for bugzilla bugs).
Many of the complaints about current postings, however, could possibly
be fixed by nicifying the kernel webpages (many people don't know much
about ``distribution kernels,'' and might happily try other kernels if
they knew how).
Another part of the problem is that there is no _official_ way of
submitting bugs. Were someone official to say ``all bugs go to bugzilla,''
(or kzilla, as the case may be), there would certainly be a better
response. Whatever the current official bugtracking mechanism is, it
should appear on the lkml webpage (atm, it does not).
Justin
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 20:42 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel, alan, lm, lm, torvalds, vonbrand, akpm
In-Reply-To: <20021219201811.GA7715@suse.de>
> > > I also don't trust things like this where if something goes wrong,
> > > we could lose the bug report.
> > How? I don't see as that is more likely than with Bugzilla.
>
> user submits bug report
> robot rejects it
It's not coded to reject stuff. Just parse it and point out obvious mistakes.
> user reads rejection, gets confused, gives up.
I do see what you mean, but that's not how I see it working:
user submits bug report
[it gets stored]
robot generates messages similar to compiler *warnings*.
> > Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
>
> Point to one important posting thats been ignored in recent times.
What about that data corruption bug that was pointed out around
2.4.18, and brought up again, when it was discovered that the patch
wasn't applied. That is a case of a bug report getting lost. Not
exactly what I meant, though, but it's relevant.
> More likely they weren't ignored, it was just deemed irrelevant,
> unimportant, or lacked information detailing how important the problem
> was.
Well, that's what the automated warnings would protect against - at
least the user would get a response, telling them how to submit a more
useful response.
> Besides, this is one area where bugzilla is helping.
> If I ignored/missed an agp related bug report on linux kernel,
> and the same user also filed it in bugzilla, I'll get pestered
> about it automatically later.
Agreed.
> > I don't see any way of making Bugzilla do all the things I described
> > originally, specifically the advanced tracking of versions tested.
>
> I still think you're solving a non-problem. Of the 180 or so bugs so
> far, there has been _1_ vendor kernel report. 1 2.4 report. and
> 1 (maybe 2) undecoded oopses (which were subsequently decoded less
> than 24hrs later.
Well, if we never get above that rate of bugs being entered in to the
database, then we might as well not have it, and go back to having
everything on LKML.
> > That could help to find duplicates, which is a big problem when you
> > have 1000+ bugs.
>
> In an ideal world, we'd never have that many open bugs 8-)
Good point :-)
> Realistically, I check bugzilla a few times a day, I notice
> when something new has been added. Near the end of each week
> I[*] go through every remaining open bug looking to see if there's
> something additional that can be added / pinging old reporters /
> closing dead bugs. Dupes usually stand out doing this.
> How exactly do you plan to automate dupe detection ?
> You can't even do things like comparing oops dumps, as they
> may have been triggered in different ways,.
I mean make it easier for people to identify dupes.
I've got loads of ideas about how we could build a better bug database
- for example, we have categories at the moment in Bugzilla. Why? We
already have a MAINTAINERS file, so say somebody looks up the relevant
maintainer in that list, finds them, then goes to enter a bug in
Bugzilla. Now they have to assign it to a category, and different
people may well assign the same bug to different categories -
immediately making duplicate detection more difficult.
If the number of bugs is always going to stay low, then my idea is
probably a waste of time, but I think that we are eventually going to
have loads of bug reports. We _want_ more bug reports, especially in
the development tree. Few enough people are testing it as it is!
John.
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Friedrich Ewaldt @ 2002-12-19 20:21 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Thierry Vignaud, alsa-devel
In-Reply-To: <s5hr8ceutxh.wl@alsa2.suse.de>
Hi!
Takashi Iwai wrote:
>At Wed, 18 Dec 2002 14:28:09 +0100,
>Friedrich Ewaldt wrote:
>
>
>>Using aplay, at the end of the audio file the last played samples get
>>repeated once. This doesn't happen with 'play', 'cat somefile /dev/dsp'
>>or 'artsplay'. But when I cause an error beep in a shell, I first hear
>>the beep and then the last samples played back before by any program
>>like aplay, play, xmms,... I can reproduce this as many time as I like,
>>i.e. the samples remain in the soundcard buffer all the time.
>>Another issue regarding aplay: playing back mono wav with a sampling
>>frequency below 44k1, the sound get's crackled. This also doesn't happen
>>with the other playback programs.
>>
>>
>
>hmm, this could have been a cause of the last hang-up.
>the unexpected interrupt was not caught by the handler.
>
>could you check /proc/asound/card0/pcm0p/sub0/hw_params for each case?
>
Here's the output of /proc/asound/card0/pcm0p/sub0/hw_params for a 8Bit
mono 11kHz wav file:
*** played with 'play'
access: RW_INTERLEAVED
format: U8
subformat: STD
channels: 1
rate: 11025 (11025/1)
period_size: 8192
buffer_size: 65536
tick_time: 10000
OSS format: U8
OSS channels: 1
OSS rate: 11025
OSS period bytes: 8192
OSS periods: 8
*** played with 'aplay'
access: RW_INTERLEAVED
format: U8
subformat: STD
channels: 1
rate: 11025 (11025/1)
period_size: 149
buffer_size: 5513
tick_time: 10000
*** xmms, oss output:
access: RW_INTERLEAVED
format: U8
subformat: STD
channels: 1
rate: 11025 (11025/1)
period_size: 256
buffer_size: 8192
tick_time: 10000
OSS format: U8
OSS channels: 1
OSS rate: 11025
OSS period bytes: 256
OSS periods: 32
*** xmms, alsa output
access: MMAP_INTERLEAVED
(if MMAP deactivated in xmms: access: RW_INTERLEAVED)
format: U8
subformat: STD
channels: 1
rate: 11025 (11025/1)
period_size: 149
buffer_size: 5513
tick_time: 10000
Sound is ok with play and xmms/OSS output, but with aplay and xmms/ALSA
it is noisy and crackled as if it were bad FM radio transmission (with
and without MMAP mode, MMAP doesn't change anything).
That's only true for mono files with low sampling rates. Stereo files
are ok using alsa or oss device.
Using xmms/ALSA, another problem occurs:
If xmms finishes playback of one file and starts the next of the
playlist, output sounds like if it were mixed with helicopter noise. To
stop this distortion I can press the 'pause' button twice or press
'stop' + 'playback'.
The same distortion occurs when I start playback of the same or another
file of the playlist while playback of one file is running. I can see
(better: hear) this problem with stereo 44kHz files and ALSA output.
Using OSS output, this problem doesn't occur.
I don't see this problem using xmms/ALSA on an similar system (some
software) with another soundcard.
>also, please try the attached patch (the drivers should be compiled
>with --with-debug=full) and see what shown in the kernel messages.
>this will print the current ply_ctrl register value.
>the patch is to the latest cvs. the cvs tree already includes the
>last fix and some additions for pause/release and spdif-out.
>
>
I patched against the cvs snapshot from december 9th with all your
previous patches applied before. I'll also test with latest cvs if I
find some more time.
Here's some output of /var/log/syslog after applaying the last patch and
compiling with debug=full:
after error beep in shell:
Dec 19 19:43:13 localhost kernel: ALSA ../alsa-kernel/pci/fm801.c:395:
prepare: ply_ctrl = 0x180
(after the beep I hear loud noise or the last audio samples played
before by any audio player. These samples are played with wrong speed,
probably because the beep is played back at another sampling rate)
after playing mono wav file 8Bit, 11kHz using aplay or play:
Dec 19 19:44:15 localhost kernel: ALSA ../alsa-kernel/pci/fm801.c:395:
prepare: ply_ctrl = 0x380
after playing stereo wav file 16Bit, 44.1kHz using aplay or play:
Dec 19 19:45:00 localhost kernel: ALSA ../alsa-kernel/pci/fm801.c:395:
prepare: ply_ctrl = 0xc980
The messages are repeated for every playback.
Do these play_ctrl values show anything? They are the same for 'aplay'
as for 'play' (and xmms, too). But playing back with native alsa apps, I
have some trouble that I don't have when I use /dev/dsp. The values seem
to depend only on the audio format. Does this info help?
ciao
fe
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values
From: David Mosberger @ 2002-12-19 20:19 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805569@msgid-missing>
>>>>> On Tue, 17 Dec 2002 08:33:38 -0800, "Patil, Harish" <harish.patil@intel.com> said:
Harish> I have a RHAS kernel compiled with *gcc3.2*. Using a script
Harish> based on readelf/objdmp I found out that there are 7
Harish> instances in this kernel where 'rlen' may be wrong. The
Harish> invariant the script is looking for is this: Sum(rlen for
Harish> various regions) = Number of slots in the code range.
Harish> The script found following violations of the invariant:
Harish> <ia64_trace_syscall>:
Harish> <ia64_ret_from_clone>:
Harish> <ia64_prepare_handle_unaligned>:
Harish> <ia32_ret_from_clone>:
Harish> <memset>:
Harish> <memcpy>:
These are all handwritten assembly routines. I think I see what's wrong:
(a) for the first 4 routines, note how they all start with an empty
prologue (e.g., PT_REGS_UNWIND_INFO(0)); these empty prologues
seem to cause gas to not count the "nop"s at the beginning of the
code. Or perhaps gas never counts the starting "nop"s and this is
just one of the places where the first instruction cannot go into
the first slot of a bundle.
(b) for memcpy and memset, I suspect the ".align 32" directives are
confusing gas
(a) is probably a bug in gas. For (b), gas can't guarantee much
because (in general) it can't know the alignment of the first
instruction of a procedure (not beyond the minimum of 16 bytes). We
should fix the assembly source here (use label_state/copy_state around
the .align directives, or get rid of them alltogether). One thing we
could do in gas, however, is add a warning so that a programmer will
know when s/he accidentally uses a .align directive inside a region.
Harish> code_range= 0xe000000004b18000-0xe000000004b182b0
Harish> lo = 4B18000 hi = 4B182B0
Harish> sum_rlen = 130 no_slots = 129
Harish> *******ERROR ***********
Harish> sum_rlen: 130 != no_slots:129
Do you know what code this is? The addresses are not terribly useful
because they'll vary from one kernel to another.
Is your script fully automatic? If so, perhaps we could add it to the
kernel sources and run it as part of "make check". I'd love to have
better unwind-info checking tools. Actually, it's even more important
to use such tools to verify the correctness of the user-level unwind
info.
Someone wants to volunteer to fix this stuff?
--david
^ permalink raw reply
* [parisc-linux] [2.5 patch] dummy console Kconfig fix
From: Bjoern A. Zeeb @ 2002-12-19 20:11 UTC (permalink / raw)
To: parisc-linux; +Cc: patch
Hi,
DUMMY_CONSOLE also needs _ROWS and _COLUMNS.
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
# CONFIG_MDA_CONSOLE is not set
# CONFIG_STI_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=160
CONFIG_DUMMY_CONSOLE_ROWS=64
--- drivers/video/console/Kconfig.orig 2002-12-19 18:45:38.000000000 +0000
+++ drivers/video/console/Kconfig 2002-12-19 18:47:14.000000000 +0000
@@ -74,9 +74,21 @@
machines. Say Y here to build support for it into your kernel.
The alternative is to use your primary serial port as a console.
+config PROM_CONSOLE
+ bool "PROM console"
+ depends on SPARC32 || SPARC64
+ help
+ Say Y to build a console driver for Sun machines that uses the
+ terminal emulation built into their console PROMS.
+
+config DUMMY_CONSOLE
+ bool
+ depends on !PROM_CONSOLE=y || VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y || !IODC_CONSOLE && GSC_PS2
+ default y
+
config DUMMY_CONSOLE_COLUMNS
int "Initial number of STI console screen columns" if STI_CONSOLE
- depends on STI_CONSOLE || FB_STI
+ depends on STI_CONSOLE || FB_STI || DUMMY_CONSOLE
default "160"
help
The default value is 160, which should fit a 1280x1024 monitor.
@@ -84,24 +96,12 @@
config DUMMY_CONSOLE_ROWS
int "Initial number of STI console screen rows" if STI_CONSOLE
- depends on STI_CONSOLE || FB_STI
+ depends on STI_CONSOLE || FB_STI || DUMMY_CONSOLE
default "64"
help
The default value is 64, which should fit a 1280x1024 monitor.
Select 25 if you use a 640x480 resolution by default.
-config PROM_CONSOLE
- bool "PROM console"
- depends on SPARC32 || SPARC64
- help
- Say Y to build a console driver for Sun machines that uses the
- terminal emulation built into their console PROMS.
-
-config DUMMY_CONSOLE
- bool
- depends on !PROM_CONSOLE=y || VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y || !IODC_CONSOLE && GSC_PS2
- default y
-
config FRAMEBUFFER_CONSOLE
tristate "Framebuffer Console support"
depends on FB
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 20:24 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200212192012.gBJKCGsV002580@darkstar.example.net>
John Bradford wrote:
> [CC list trimmed]
>
>
>>> > >It could warn the user if they attach an un-decoded oops that their
>>> > >bug report isn't as useful as it could be, and if they mention a
>>> > >distribution kernel version, that it's not a tree that the developers
>>> > >will necessarily be familiar with
>>> > Perhaps a more generalized hook into bugzilla for 'validating' a bug
>>> > report, then code specific validators for kernel work?
>>>
>>>Its a nice idea, but I think it's a lot of effort to get it right,
>>>when a human can look at the dump, realise its not decoded, and
>>>send a request back in hardly any time at all.
>>>I also don't trust things like this where if something goes wrong,
>>>we could lose the bug report. People are also more likely to ping-pong
>>>,argue or "how do I..." with a human than they are with an automated robot.
>>
>>Either way, it isn't kernel specific.... which is what I was trying to
>>address. If it is valuable (which as you demonstrate is debatable,)
>>then it is valuable in bugzilla baseline, not just kernel-bugzilla.
>
>
> What!? Parsing an oops isn't kernel specific?
No, no, you mis-understand. A bug report going through some sort of
validation filter is applicable to any project. A validation script
that checks for a very close match to existing bugs for instance, and
asks the submitter about it, would be widely applicable.
Parsing an oops would be a kernel-specific validation filter.
> Version tracking over
> multiple separate trees as diverse as 2.4 and 2.5 isn't pretty kernel
> specific?
No, it isn't. There are a lot of projects out there that use a
'development' and 'stable' tree, and some that use more. bugzilla
itself does this. Trolltech's Qt has several version branches.
We do have more development branches than most, but we are not unique.
My point is that this is functionality that makes sense for the base
version of the bug tracking software, not just for the kernel version.
> In any case, people could take the kernel bug database, and
> genericify it, much more easily than somebody could tailor an existing
> bug tracking application to the needs of the kernel, (which is
> demonstrated by the fact that the developers are not getting Bugzilla
> reports).
Perhaps, but I'm not convinced that it would be easier to write a kernel
bug database from scratch than it would be to improve an existing
project to address the kernel's needs. And _that_ is what we were
discussing.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 20:32 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.3.96.1021219150117.29410B-100000@gatekeeper.tmr.com>
> > Following on from yesterday's discussion about there not being much
> > interaction between the kernel Bugzilla and the developers, I began
> > wondering whether Bugzilla might be a bit too generic to be suited to
> > kernel development, and that maybe a system written from the ground up
> > for reporting kernel bugs would be better?
> >
> > I.E. I am prepared to write it myself, if people think it's
> > worthwhile.
>
> Hopefully you could make it more generic than just for kernel bugs.
Well, my intention was to write it based around being used for kernel
bugs, and let others modify it for their needs, (and presumably
Bugzilla was based around being used for reporting bugs in a web
browser).
> Ideally it would be nice to be able to have both an interactive submission
> and a way to mail a version number and get back a questionare to fill in
> and resubmit. This allows for a custom form for some versions, as well as
> another mail back listing known bugs fixed in later versions, to avoid
> reporting fixed bugs.
Interesting - so the first stage in reporting a bug would be to select
the latest 2.4 and 2.5 kernels that you've noticed it in, and get a
list of known bugs fixed in those versions. Also, if you'd selected
the maintainer, (from an automatically generated list from the
MAINTAINERS file), it could just search *their* changes in the changelog.
> I'm not sure if it would be possible to make a frontend to bugzilla, I'm
> not thrilled with the whole thing, but I have no illusions of having
> enough free time to tackle anything that large.
I'm prepared to have a go at it. This _is_ my kind of area - most of
my income this year has come from writing web-based database code :-).
> Doing interesting things with little computers since 1979.
Were you doing boring things with large computers before then? :-)
:-) :-). Sorry, I'm being silly now :-).
John.
^ permalink raw reply
* sym53c8xx_2 fix
From: Bjorn Helgaas @ 2002-12-19 20:14 UTC (permalink / raw)
To: groudier; +Cc: linux-scsi, gibbs
We run the sym53c8xx_2 driver on a simulator. Because the
simulator's disk model is somewhat simplified compared to real
hardware, it exercises some code paths that are not exercised
on the hardware.
Our simulator guru found what appears to be an error in
one such path. Here's his description and patch (against
2.4.20). Let me know if you need more information.
Justin, I copied you because the comment immediately preceding
this code says it's part of an optimization you suggested
(negotiating for SYNC immediately after a WIDE response).
> ... There is also a bug in the driver that keeps us from
> booting. This code path is not executed on hardware but is on the sim with
> our simple disk model. The current driver assembles an SDTR request but
> then calls the SDTR response script. Here is the fix:
> --- orig/linux-ia64-2.4/drivers/scsi/sym53c8xx_2/sym_hipd.c Fri Sep 27 17:27:41 2002
> +++ fixed/linux-ia64-2.4/drivers/scsi/sym53c8xx_2/sym_hipd.c Wed Dec 18 21:26:25 2002
> @@ -4363,7 +4363,7 @@
>
> cp->nego_status = NS_SYNC;
> OUTB (HS_PRT, HS_NEGOTIATE);
> - OUTL_DSP (SCRIPTB_BA (np, sdtr_resp));
> + OUTL_DSP (SCRIPTB_BA (np, send_sdtr));
> return;
> }
--
Bjorn Helgaas - bjorn_helgaas at hp.com
Linux and Open Source Lab
Hewlett-Packard Company
^ permalink raw reply
* module_list not exported
From: Thomas Heinz @ 2002-12-19 20:23 UTC (permalink / raw)
To: linux-kernel
Hi
Just a short question. Why are module_list and modlist_lock not
exported as symbols in 2.4? If they were available it would be very
easy to realize some kind of module autoloading mechanism for example.
Just loading the module via request_module and afterwards getting the
corresponding struct module * by searching through module_list
(and of course incrementing use count).
It would be kind if you could cc to my private e-mail as I'm
currently not subscribed. Thank you.
Regards
Thomas
^ permalink raw reply
* Sony Vaio Battery Info
From: Markus Gaugusch @ 2002-12-19 20:13 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
As previously written, reading the battery info on sony vaio laptops
(FX/FXA series) takes very long time (~0.6 sec). Battery state takes only
~0.1 sec, but this is still too long for constantly using a battery
monitor.
I'd like to find the bug, but need some help. My first idea is to put time
stamps to the debug messages. Bob Moore suggested to begin with the EC
code.
I don't really know how to do this (finding the ec code won't be so hard,
but I don't think that 'normal' libc time functions will work in kernel).
Any volunteers? ;)
Markus
--
__________________ /"\
Markus Gaugusch \ / ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org X Against HTML Mail
/ \
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* RE: AW: Re: [PATCH] S4bios for 2.5.52.
From: Nigel Cunningham @ 2002-12-19 20:12 UTC (permalink / raw)
To: 'Lyle Seaman'
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
'Herbert Nachtnebel'
In-Reply-To: <20021219150600.C5DBE1480A-RAHWjsxJnJUdnm+yROfE0A@public.gmane.org>
Hmm. I didn't think that carefully about what was causing the write to
occur. Hence I unrolled I took your patch further and completely separated
the submitting of _all_ of the pages from the block_flushpage calls for all
of the pages (ie two loops). (I saw much more than a one second gain, even
on my faster desktop computer!) After reading this, I think I should look
sooner at what is going. I was going to anyway, but I was concentrating on
getting my whole port from 2.4 working first.
I'm not promising anything quickly - I have plenty of 'real' work at the
moment :>
Regards,
Nigel
> Still, writing pages synchronously, one at a time, is going
> to be slow no
> matter what you do. *Especially* on slow laptop drives.
>
> What I sent Nigel was a little patch to write them 20 at a
> time, which reduced
> my suspend times from nearly 60 seconds to something around 2
> seconds. I
> stopped at 20 because going beyond that was chasing
> diminishing returns and I
> didn't think that chewing up a huge chunk of stack was
> justified for a
> one-second reduction in suspend times.
>
> I didn't send it on to the rest of the list because I figure
> Nigel's other
> changes will be coming along as well, and I didn't want to
> make merging too
> difficult for everyone.
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Patch(2.5.52): Add missing PCI ID's for nVidia IDE and PlanB frame grabber
From: Michel Lanners @ 2002-12-19 20:17 UTC (permalink / raw)
To: alan; +Cc: adam, mj, axboe, andre, toe, kraxel, linux-kernel
In-Reply-To: <1040259741.26882.0.camel@irongate.swansea.linux.org.uk>
On 19 Dec, this message from Alan Cox echoed through cyberspace:
> On Wed, 2002-12-18 at 23:35, Adam J. Richter wrote:
>> Hi Martin,
>>
>> This patch adds two pci device id definitions needed to make
>> a couple of drivers compile in 2.5.52:
>>
>> drivers/ide/pci/nvidia.c needs PCI_DEVICE_IDE_NVIDIA_NFORCE_IDE
>> drivers/media/video/planb.c needs PCI_DEVICE_IDE_APPLE_PLANB
>>
>> If nobody complains, could you please forward these changes to
>> Linus and confirm to me that you have done this (so I can have a
>> better idea of what to do if they not appear in 2.5.53)? Thanks in
>> advance.
>
> The NVIDIA one is right, someoen removed it from Linus tree by accident
> in 2.5.51 or so when adding other Nvidia bits.
The PLANB one is right as well; it probably never was in there, but is
indeed useful to the driver.
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Dave Jones @ 2002-12-19 20:18 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel, alan, lm, lm, torvalds, vonbrand, akpm
In-Reply-To: <200212191952.gBJJqTb3002477@darkstar.example.net>
On Thu, Dec 19, 2002 at 07:52:29PM +0000, John Bradford wrote:
> > I also don't trust things like this where if something goes wrong,
> > we could lose the bug report.
> How? I don't see as that is more likely than with Bugzilla.
user submits bug report
robot rejects it
user reads rejection, gets confused, gives up.
> Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
Point to one important posting thats been ignored in recent times.
More likely they weren't ignored, it was just deemed irrelevant,
unimportant, or lacked information detailing how important the problem
was.
Besides, this is one area where bugzilla is helping.
If I ignored/missed an agp related bug report on linux kernel,
and the same user also filed it in bugzilla, I'll get pestered
about it automatically later.
> I don't see any way of making Bugzilla do all the things I described
> originally, specifically the advanced tracking of versions tested.
I still think you're solving a non-problem. Of the 180 or so bugs so
far, there has been _1_ vendor kernel report. 1 2.4 report. and
1 (maybe 2) undecoded oopses (which were subsequently decoded less
than 24hrs later.
> That could help to find duplicates, which is a big problem when you
> have 1000+ bugs.
In an ideal world, we'd never have that many open bugs 8-)
Realistically, I check bugzilla a few times a day, I notice
when something new has been added. Near the end of each week
I[*] go through every remaining open bug looking to see if there's
something additional that can be added / pinging old reporters /
closing dead bugs. Dupes usually stand out doing this.
How exactly do you plan to automate dupe detection ?
You can't even do things like comparing oops dumps, as they
may have been triggered in different ways,.
Dave
[*] and hopefully, I'm not the only one who does this.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: reiserfsck --rebuild-tree on a big filesystem
From: Zygo Blaxell @ 2002-12-19 20:09 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <20021219200020.A7258@namesys.com>
In article <20021219200020.A7258@namesys.com>,
Oleg Drokin <green@namesys.com> wrote:
>Part of this problem is solved - get latest 3.6.5-pre version of reiserfsprogs
>and give it a try.
In less than 7 hours pass 0 will be done, at 600-1900 blocks per second.
Memory usage is also constant now--the reiserfsck process has been at
24104K since it started.
>Also there is similar problem expected at semantic pass that was not dealt with
>because we are not yet sure how to solve that.
I guess I'll find out in 7 hours what the semantic pass will be like.
Fortunately I don't need to use this particular filesystem until 2003,
so there is time to run little experiments like this...
--
Opinions expressed are my own, I don't speak for my employer, and all that.
Encrypted email preferred. Go ahead, you know you want to. ;-)
OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D
^ permalink raw reply
* RE: Re: [PATCH] S4bios for 2.5.52.
From: Nigel Cunningham @ 2002-12-19 20:04 UTC (permalink / raw)
To: 'Herbert Nachtnebel',
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <B900970C7DD9474C972986EB3EC7C58F0D404E-PWLG29+z7hEKeIAE67mlpo2P0GrZ+RbP@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
I don't think so, because AFAIK the bdflush daemon is in the refrigerator by
this point and it is consistently when a particular page number is submitted
that the first 'flush' occurs. I thought it might be that some threshhold is
reached. Oh - just in case there's anyone wondering, I'm not trying to write
to anything other than an IDE swap partition :>
Regards,
Nigel
> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org]On Behalf Of Herbert
> Nachtnebel
> Sent: Thursday, December 19, 2002 10:49 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: AW: [ACPI] Re: [PATCH] S4bios for 2.5.52.
>
>
> Sorry to be stupid,
>
> but that sounds like a unpluged block queue which get flushed
> every 5 seconds (or 30 seconds) by the bdflush daemon. There
> are two things which counters this, 1st: swsusp works on ide
> and there aren't such problems since aeons and 2nd Pavel
> knows that :-)
> Hence, apologies for this hip shot.
>
> Herbert.
>
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2364 bytes --]
^ permalink raw reply
* AMD Config Advice
From: Frank R Callaghan @ 2002-12-19 20:31 UTC (permalink / raw)
To: LinuxMTD
Hi,
I undrstand this may be a very basic question, but here go's
I am looking to use an AMD flash chip on my pc104 card
to store some non-volatile data, the chip is a 2MB part AMD29F016,
the BIOS is in the top 128KB of the first mega-byte(do not want to overwrite).
After setting up the kernel with MDT I get
cat /proc/mtd
dev: size erasesize name
mtd0: 00200000 00010000 "Physically mapped flash"
ok but I only need the second 1MB - is there some way to either
prevent the first meg being mapped/used ?
Kernal Version 2.4.19 with:
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
# CONFIG_MTD_PARTITIONS is not set
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CHAR is not set
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
# CONFIG_NFTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set
#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=9500000 <- My phy addr of second MB
CONFIG_MTD_PHYSMAP_LEN=100000 <-- 1MB
CONFIG_MTD_PHYSMAP_BUSWIDTH=1
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_SC520CDP is not set
# CONFIG_MTD_NETSC520 is not set
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_ELAN_104NC is not set
# CONFIG_MTD_DILNETPC is not set
# CONFIG_MTD_MIXMEM is not set
# CONFIG_MTD_OCTAGON is not set
# CONFIG_MTD_VMAX is not set
# CONFIG_MTD_L440GX is not set
# CONFIG_MTD_AMD766ROM is not set
# CONFIG_MTD_ICH2ROM is not set
# CONFIG_MTD_PCI is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set
also I'm looking to use jffs2 as the file system - maybe I can partion it
to only use the second meg ???
TIA,
Frank.
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Bill Davidsen @ 2002-12-19 20:09 UTC (permalink / raw)
To: John Bradford; +Cc: Linux-Kernel Mailing List
In-Reply-To: <200212191335.gBJDZRDL000704@darkstar.example.net>
On Thu, 19 Dec 2002, John Bradford wrote:
> Following on from yesterday's discussion about there not being much
> interaction between the kernel Bugzilla and the developers, I began
> wondering whether Bugzilla might be a bit too generic to be suited to
> kernel development, and that maybe a system written from the ground up
> for reporting kernel bugs would be better?
>
> I.E. I am prepared to write it myself, if people think it's
> worthwhile.
Hopefully you could make it more generic than just for kernel bugs.
Ideally it would be nice to be able to have both an interactive submission
and a way to mail a version number and get back a questionare to fill in
and resubmit. This allows for a custom form for some versions, as well as
another mail back listing known bugs fixed in later versions, to avoid
reporting fixed bugs.
I'm not sure if it would be possible to make a frontend to bugzilla, I'm
not thrilled with the whole thing, but I have no illusions of having
enough free time to tackle anything that large.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.