* 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
* [PATCH]: fix type of MAXMEM
From: Juan Quintela @ 2002-12-19 20:07 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
I expect that the amount from where it is highmem to never be
bigger that 4Giga Megabytes :) I.e. int should be enough.
Later, Juan.
Index: arch/mips/kernel/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/setup.c,v
retrieving revision 1.96.2.34
diff -u -r1.96.2.34 setup.c
--- arch/mips/kernel/setup.c 11 Dec 2002 06:12:29 -0000 1.96.2.34
+++ arch/mips/kernel/setup.c 19 Dec 2002 19:48:41 -0000
@@ -306,7 +306,7 @@
max_low_pfn = MAXMEM_PFN;
#ifndef CONFIG_HIGHMEM
/* Maximum memory usable is what is directly addressable */
- printk(KERN_WARNING "Warning only %ldMB will be used.\n",
+ printk(KERN_WARNING "Warning only %dMB will be used.\n",
MAXMEM>>20);
printk(KERN_WARNING "Use a HIGHMEM enabled kernel.\n");
#endif
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Juan Quintela @ 2002-12-19 20:04 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
this small patch made possible to compile a 64bit kernel for
people that have old proms that only accept ecoff. As usual
stolen from the 32 bits version.
The easiest way is creating the file in arch/mips/boot,
otherwise we need to copy elf2ecoff.c to mips64.
Later, Juan.
Index: arch/mips64/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips64/Makefile,v
retrieving revision 1.22.2.20
diff -u -r1.22.2.20 Makefile
--- arch/mips64/Makefile 26 Nov 2002 11:19:52 -0000 1.22.2.20
+++ arch/mips64/Makefile 19 Dec 2002 19:48:43 -0000
@@ -255,6 +255,9 @@
$(OBJCOPY) -O $(64bit-bfd) --remove-section=.reginfo --change-addresses=0xa800000080000000 $< $@
endif
+vmlinux.ecoff: vmlinux
+ $(MAKE) -C arch/mips/boot $@
+
zImage: vmlinux
@$(MAKEBOOT) zImage
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH]: Remove 2 unused variables
From: Juan Quintela @ 2002-12-19 20:02 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
errno and p are not used in that function at all.
Later, Juan.
Index: arch/mips64/kernel/syscall.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/kernel/syscall.c,v
retrieving revision 1.16.2.7
diff -u -r1.16.2.7 syscall.c
--- arch/mips64/kernel/syscall.c 5 Aug 2002 23:53:36 -0000 1.16.2.7
+++ arch/mips64/kernel/syscall.c 19 Dec 2002 19:48:43 -0000
@@ -189,9 +189,8 @@
asmlinkage int
sys_sysmips(int cmd, long arg1, int arg2, int arg3)
{
- int *p;
char *name;
- int tmp, len, errno;
+ int tmp, len;
switch(cmd) {
case SETNAME: {
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH]: flasg needs to be unsigned long
From: Juan Quintela @ 2002-12-19 20:01 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
subject told all.
Once there, put they inside the right #ifdef
Later, Juan.
Index: arch/mips64/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/c-r4k.c,v
retrieving revision 1.1.2.9
diff -u -r1.1.2.9 c-r4k.c
--- arch/mips64/mm/c-r4k.c 18 Dec 2002 22:43:22 -0000 1.1.2.9
+++ arch/mips64/mm/c-r4k.c 19 Dec 2002 19:48:44 -0000
@@ -948,12 +948,13 @@
static void r4k_dma_cache_wback_inv_pc(unsigned long addr, unsigned long size)
{
unsigned long end, a;
- unsigned int flags;
if (size >= dcache_size) {
flush_cache_l1();
} else {
#ifdef R4600_V2_HIT_CACHEOP_WAR
+ unsigned long flags;
+
/* Workaround for R4600 bug. See comment in <asm/war>. */
__save_and_cli(flags);
*(volatile unsigned long *)KSEG1;
@@ -994,12 +995,13 @@
static void r4k_dma_cache_inv_pc(unsigned long addr, unsigned long size)
{
unsigned long end, a;
- unsigned int flags;
if (size >= dcache_size) {
flush_cache_l1();
} else {
#ifdef R4600_V2_HIT_CACHEOP_WAR
+ unsigned long flags;
+
/* Workaround for R4600 bug. See comment in <asm/war>. */
__save_and_cli(flags);
*(volatile unsigned long *)KSEG1;
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [PATCH 2.5.52] Use __set_current_state() instead of current->state = (take 3)
From: Inaky Perez-Gonzalez @ 2002-12-19 19:57 UTC (permalink / raw)
To: linux-kernel, rml, torvalds
Hi all
In fs/*.c, many functions manually set the task state directly
accessing current->state, or with a macro, kind of
inconsistently. This patch changes all of them to use
[__]set_current_state().
Changelog:
- Use safe set_current_state() instead of __set... in
exec.c:de_thread()
Take 2:
- Added feedback from Robert Love regarding usage of
__set_current_thread() vs. set_current_thread() to avoid race
conditions related to memory flush.
- Use cond_resched() in namei.c:do_follow_link().
Take 1:
- Ported forward to 2.5.52
diff -u fs/dquot.c:1.1.1.4 fs/dquot.c:1.1.1.1.6.2
--- fs/dquot.c:1.1.1.4 Wed Dec 11 11:13:35 2002
+++ fs/dquot.c Wed Dec 18 13:20:24 2002
@@ -264,7 +264,7 @@
goto repeat;
}
remove_wait_queue(&dquot->dq_wait_lock, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
static inline void wait_on_dquot(struct dquot *dquot)
@@ -298,7 +298,7 @@
goto repeat;
}
remove_wait_queue(&dquot->dq_wait_free, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
/* Wait for all duplicated dquot references to be dropped */
@@ -314,7 +314,7 @@
goto repeat;
}
remove_wait_queue(&dquot->dq_wait_free, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
static int read_dqblk(struct dquot *dquot)
diff -u fs/exec.c:1.1.1.8 fs/exec.c:1.1.1.1.6.3
--- fs/exec.c:1.1.1.8 Mon Dec 16 18:44:31 2002
+++ fs/exec.c Wed Dec 18 18:23:23 2002
@@ -587,7 +587,7 @@
count = 1;
while (atomic_read(&oldsig->count) > count) {
oldsig->group_exit_task = current;
- current->state = TASK_UNINTERRUPTIBLE;
+ set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irq(&oldsig->siglock);
schedule();
spin_lock_irq(&oldsig->siglock);
diff -u fs/inode.c:1.1.1.6 fs/inode.c:1.1.1.1.6.2
--- fs/inode.c:1.1.1.6 Mon Dec 16 18:44:31 2002
+++ fs/inode.c Wed Dec 18 13:20:24 2002
@@ -1195,7 +1195,7 @@
goto repeat;
}
remove_wait_queue(wq, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
}
void wake_up_inode(struct inode *inode)
diff -u fs/locks.c:1.1.1.6 fs/locks.c:1.1.1.1.6.3
--- fs/locks.c:1.1.1.6 Wed Dec 11 11:13:35 2002
+++ fs/locks.c Wed Dec 18 17:42:37 2002
@@ -571,7 +571,7 @@
int result = 0;
DECLARE_WAITQUEUE(wait, current);
- current->state = TASK_INTERRUPTIBLE;
+ set_current_state (TASK_INTERRUPTIBLE);
add_wait_queue(fl_wait, &wait);
if (timeout == 0)
schedule();
@@ -580,7 +580,7 @@
if (signal_pending(current))
result = -ERESTARTSYS;
remove_wait_queue(fl_wait, &wait);
- current->state = TASK_RUNNING;
+ __set_current_state (TASK_RUNNING);
return result;
}
diff -u fs/namei.c:1.1.1.6 fs/namei.c:1.1.1.1.6.3
--- fs/namei.c:1.1.1.6 Wed Dec 11 11:13:35 2002
+++ fs/namei.c Wed Dec 18 17:42:49 2002
@@ -409,10 +409,7 @@
goto loop;
if (current->total_link_count >= 40)
goto loop;
- if (need_resched()) {
- current->state = TASK_RUNNING;
- schedule();
- }
+ cond_resched();
err = security_inode_follow_link(dentry, nd);
if (err)
goto loop;
diff -u fs/select.c:1.1.1.3 fs/select.c:1.1.1.1.6.2
--- fs/select.c:1.1.1.3 Wed Dec 11 11:10:14 2002
+++ fs/select.c Wed Dec 18 13:20:24 2002
@@ -235,7 +235,7 @@
}
__timeout = schedule_timeout(__timeout);
}
- current->state = TASK_RUNNING;
+ __set_current_state (TASK_RUNNING);
poll_freewait(&table);
@@ -417,7 +417,7 @@
break;
timeout = schedule_timeout(timeout);
}
- current->state = TASK_RUNNING;
+ __set_current_state (TASK_RUNNING);
return count;
}
--
Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are my own [or my fault]
^ permalink raw reply
* [PATCH]:
From: Juan Quintela @ 2002-12-19 20:00 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
- pte_val() returs a long, print it directly.
- flags needs to be unsigedn long, not unsigned int.
Later, Juan.
Later, Juan.
Index: arch/mips64/mm/tlb-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/tlb-r4k.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 tlb-r4k.c
--- arch/mips64/mm/tlb-r4k.c 2 Dec 2002 00:24:53 -0000 1.1.2.5
+++ arch/mips64/mm/tlb-r4k.c 19 Dec 2002 19:48:44 -0000
@@ -244,7 +244,7 @@
pmd = pmd_offset(pgd, addr);
pte = pte_offset(pmd, addr);
page = *pte;
- printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
+ printk("Memory Mapping: VA = %08x, PA = %08x ", addr, pte_val(page));
val = pte_val(page);
if (val & _PAGE_PRESENT) printk("present ");
if (val & _PAGE_READ) printk("read ");
@@ -259,7 +259,7 @@
void show_tlb(void)
{
- unsigned int flags;
+ unsigned long flags;
unsigned int old_ctx;
unsigned int entry;
unsigned int entrylo0, entrylo1, entryhi;
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 20:12 UTC (permalink / raw)
To: Eli Carter; +Cc: linux-kernel
In-Reply-To: <3E0222E4.5070104@inet.com>
[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? Version tracking over
multiple separate trees as diverse as 2.4 and 2.5 isn't pretty kernel
specific? 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).
John.
^ permalink raw reply
* Re: Hammerfall configuration
From: patrick reardon @ 2002-12-19 19:52 UTC (permalink / raw)
To: Paul Davis
Cc: alsa-devel@lists.sourceforge.net, alsa-user@lists.sourceforge.net
In-Reply-To: <200212191130.18p6nx3RJ3NZFl40@penguin>
Paul Davis wrote:
>
> >line added to /etc/rc.d/rc.sysinit:
> >
> >action "Loading ALSA Hammerfall driver" modprobe snd-rme9652
> >
> >/etc/modules.conf is set to load soundcore and snd-rme9652-mem before
> >snd-rme9 652, so this takes care of it.
>
> this is not quite right. rc.sysint should load just
> snd-rme9652-mem. it will work the way you have it, but there is no
> reason to load snd-rme9652 in rc.sysinit - this (unlike
> snd-rme9652-mem) will require loading of all of the ALSA
> infrastructure as well.
i go ahead and do it anyway so i don't have to bother with it later, but i see your
point. the *-mem module is the only one that really needs to be loaded early.
>
> >action "Setting Hammerfall as master clock" alsactl restore snd-rme9652
> >
> >can be added after the modprobe command.
>
> this will happen anyway if /etc/asound.state contains the relevant
> setting for the card. that is, if you've set it to master, and ALSA is
> shutdown normally, then /etc/asound.state will be used to reset the
> state when the alsasound init script runs.
ah. a few days ago i removed the alsasound init script and just did everything by hand
trying to debug this problem. guess i should put it back :-[
patrick
-------------------------------------------------------
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: device interface api
From: Patrick Mochel @ 2002-12-19 19:31 UTC (permalink / raw)
To: Martin Waitz; +Cc: linux-kernel
In-Reply-To: <20021218004039.GA1115@admingilde.org>
> int interface_add_data(struct intf_data * data)
> {
> struct device_interface * intf = intf_from_data(data);
>
> data->intf_num = data->intf->devnum++;
> data->kobj.subsys = &intf->subsys;
> kobject_register(&data->kobj);
> [...]
>
>
> data->kobj.subsys is initialized here, but intf_from_data
> is using this data->kobj.subsys to get intf, instead of data->intf.
> do you want to remove data->intf?
> either way, interface_add_data should change.
>
> are interface users supposed to set data->intf or data->kobj.subsys?
The former. The appended patch should fix that. Sorry about that.
> another small glitch i noticed while diggin in the code:
>
> ================================================================
> --- linux-2.5/lib/kobject.c Tue Dec 10 12:59:02 2002
> +++ linux/lib/kobject.c Tue Dec 17 13:15:19 2002
> @@ -218,7 +218,7 @@ int subsystem_register(struct subsystem
> s->kobj.parent = &s->parent->kobj;
> pr_debug("subsystem %s: registering, parent: %s\n",
> s->kobj.name,s->parent ? s->parent->kobj.name : "<none>");
> - return kobject_register(&s->kobj);
> + return kobject_add(&s->kobj);
> }
>
> void subsystem_unregister(struct subsystem * s)
> ================================================================
>
> subsystem_register first calls subsystem_init, which already
> does kobject_init, so a full kobject_register is not needed
> (and is in fact bad, as it again increases the refcounter for kobj.subsys)
Nice catch. The internal semantics changed a while back, and I missed that
one when fixing up the users. A fix for that is also inluded in the
following patch.
-pat
===== drivers/base/intf.c 1.9 vs edited =====
--- 1.9/drivers/base/intf.c Tue Dec 3 12:40:21 2002
+++ edited/drivers/base/intf.c Thu Dec 19 13:04:56 2002
@@ -14,9 +14,6 @@
#define to_data(e) container_of(e,struct intf_data,kobj.entry)
-#define intf_from_data(d) container_of(d->kobj.subsys,struct device_interface, subsys);
-
-
/**
* intf_dev_link - create sysfs symlink for interface.
* @data: interface data descriptor.
@@ -61,15 +58,18 @@
int interface_add_data(struct intf_data * data)
{
- struct device_interface * intf = intf_from_data(data);
+ struct device_interface * intf = data->intf;
- data->intf_num = data->intf->devnum++;
- data->kobj.subsys = &intf->subsys;
- kobject_register(&data->kobj);
-
- list_add_tail(&data->dev_entry,&data->dev->intf_list);
- intf_dev_link(data);
- return 0;
+ if (intf) {
+ data->intf_num = intf->devnum++;
+ data->kobj.subsys = &intf->subsys;
+ kobject_register(&data->kobj);
+
+ list_add_tail(&data->dev_entry,&data->dev->intf_list);
+ intf_dev_link(data);
+ return 0;
+ }
+ return -EINVAL;
}
@@ -121,9 +121,9 @@
static void del(struct intf_data * data)
{
- struct device_interface * intf = intf_from_data(data);
+ struct device_interface * intf = data->intf;
- pr_debug(" -> %s ",data->intf->name);
+ pr_debug(" -> %s ",intf->name);
interface_remove_data(data);
if (intf->remove_device)
intf->remove_device(data);
===== include/linux/kobject.h 1.8 vs edited =====
--- 1.8/include/linux/kobject.h Thu Nov 21 17:01:53 2002
+++ edited/include/linux/kobject.h Thu Dec 19 13:05:41 2002
@@ -52,7 +52,7 @@
static inline struct subsystem * subsys_get(struct subsystem * s)
{
- return container_of(kobject_get(&s->kobj),struct subsystem,kobj);
+ return s ? container_of(kobject_get(&s->kobj),struct subsystem,kobj) : NULL;
}
static inline void subsys_put(struct subsystem * s)
===== lib/kobject.c 1.9 vs edited =====
--- 1.9/lib/kobject.c Sun Dec 1 23:24:33 2002
+++ edited/lib/kobject.c Thu Dec 19 13:00:05 2002
@@ -74,10 +74,13 @@
{
int error = 0;
struct subsystem * s = kobj->subsys;
- struct kobject * parent = kobject_get(kobj->parent);
+ struct kobject * parent;
if (!(kobj = kobject_get(kobj)))
return -ENOENT;
+
+ parent = kobject_get(kobj->parent);
+
pr_debug("kobject %s: registering. parent: %s, subsys: %s\n",
kobj->name, parent ? parent->name : "<NULL>",
kobj->subsys ? kobj->subsys->kobj.name : "<NULL>" );
@@ -93,8 +96,8 @@
up_write(&s->rwsem);
}
error = create_dir(kobj);
- if (error && kobj->parent)
- kobject_put(kobj->parent);
+ if (error && parent)
+ kobject_put(parent);
return error;
}
@@ -218,7 +221,7 @@
s->kobj.parent = &s->parent->kobj;
pr_debug("subsystem %s: registering, parent: %s\n",
s->kobj.name,s->parent ? s->parent->kobj.name : "<none>");
- return kobject_register(&s->kobj);
+ return kobject_add(&s->kobj);
}
void subsystem_unregister(struct subsystem * s)
^ permalink raw reply
* [PATCH]: put show_regs in a header file
From: Juan Quintela @ 2002-12-19 19:56 UTC (permalink / raw)
To: Ralf Baechle, mipslist
Hi
this is the same place where it is exported in 32 bits.
Later, Juan.
Index: include/asm-mips64/ptrace.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/ptrace.h,v
retrieving revision 1.6.4.3
diff -u -r1.6.4.3 ptrace.h
--- include/asm-mips64/ptrace.h 27 Jun 2002 14:21:24 -0000 1.6.4.3
+++ include/asm-mips64/ptrace.h 19 Dec 2002 19:48:51 -0000
@@ -76,6 +76,7 @@
#ifndef __ASSEMBLY__
#define instruction_pointer(regs) ((regs)->cp0_epc)
+extern void show_regs(struct pt_regs *);
#endif /* !__ASSEMBLY__ */
#endif
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 20:08 UTC (permalink / raw)
To: Eli Carter; +Cc: dank, linux-kernel
In-Reply-To: <3E020B37.4070409@inet.com>
> 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.
Whenever somebody posts a bug report to LKML, quite often the first
thing somebody asks them is whether they have tried another kernel
version. Most people don't have the time to try more than, say,
three different versions, and a lot of people might not want to use
the 2.5 development tree.
We _need_ a way to add data to a bug report like this:
* Original bug reporter reports a bug in 2.4.20. It was also in
2.4.19
* Somebody else tries older versions, and discovers that it was
introduced in 2.4.15
* A third person discovers that recent 2.5 kernels are not affected,
because the code has been re-written.
Each time, information is added to the bug database _in a way that can
be easily searched_, not just as comments which cannot.
I don't know of an existing bug database system which can do that, or
is close to being able to do that.
John.
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 19:49 UTC (permalink / raw)
To: Dave Jones
Cc: John Bradford, linux-kernel, alan, lm, lm, torvalds, vonbrand,
akpm
In-Reply-To: <20021219184958.GA6837@suse.de>
Dave Jones wrote:
> On Thu, Dec 19, 2002 at 11:48:16AM -0600, Eli Carter wrote:
[snip]
> > >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.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: Hammerfall configuration
From: Paul Davis @ 2002-12-19 19:34 UTC (permalink / raw)
To: patrick reardon
Cc: alsa-devel@lists.sourceforge.net, alsa-user@lists.sourceforge.net
In-Reply-To: <3E021AE9.29565751@earthlink.net>
>it works! disks burn correctly now. thanks to everyone who helped
>me get thi s straightened out, especially paul davis and joerg
>shilling. in case it might help someone else, i'm running a redhat
>based system and load the hammerfall modules at boo t time with this
>line added to /etc/rc.d/rc.sysinit:
>
>action "Loading ALSA Hammerfall driver" modprobe snd-rme9652
>
>/etc/modules.conf is set to load soundcore and snd-rme9652-mem before
>snd-rme9 652, so this takes care of it.
this is not quite right. rc.sysint should load just
snd-rme9652-mem. it will work the way you have it, but there is no
reason to load snd-rme9652 in rc.sysinit - this (unlike
snd-rme9652-mem) will require loading of all of the ALSA
infrastructure as well.
>action "Setting Hammerfall as master clock" alsactl restore snd-rme9652
>
>can be added after the modprobe command.
this will happen anyway if /etc/asound.state contains the relevant
setting for the card. that is, if you've set it to master, and ALSA is
shutdown normally, then /etc/asound.state will be used to reset the
state when the alsasound init script runs.
--p
-------------------------------------------------------
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: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 19:52 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel, alan, lm, lm, torvalds, vonbrand, akpm
In-Reply-To: <20021219184958.GA6837@suse.de>
> > >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.
Somebody still has to answer it - loads of mails to LKML go unanswered
because people are spending their time coding instead of reading the
list, (which is good).
> 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. Anyway,
loads of LKML posts get ignored, and nobody seems to worry about it :-).
> People are also more likely to ping-pong ,argue or "how do I..."
> with a human than they are with an automated robot.
The idea is that the bug database does a sanity check on their bug
report. It still gets entered in to the database, but it would return
something like:
"
Hi,
You submitted a bug to the bug database. Please note the following:
* You mentioned kernel version foobar. This appears to be a vendor
kernel, not an official kernel tree. Your distribution maintainers
might be more appropriate people to contact
* You included an undecoded oops - this is probably useless. Please
read the FAQ.
Thanks for using the bug database. Your bug has been assigned to
[whoever].
"
I don't see any way of making Bugzilla do all the things I described
originally, specifically the advanced tracking of versions tested.
That could help to find duplicates, which is a big problem when you
have 1000+ bugs.
John.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-19 19:37 UTC (permalink / raw)
To: bart
Cc: davej, lk, hpa, terje.eggestad, drepper, matti.aarnio, hugh,
mingo, linux-kernel
In-Reply-To: <20021219135517.7E78051FB6@gum12.etpnet.phys.tue.nl>
On Thu, 19 Dec 2002 bart@etpmod.phys.tue.nl wrote:
>
> True, but unless I really don't get it, compatibility of a new static
> binary with an old kernel is going to break anyway.
NO.
The current code in 2.5.x is perfectly able to be 100% compatible with
binaries even on old kernels. This whole discussion is _totally_
pointless. I solved all the glibc problems early on, and Uli is already
happy with the interfaces, and they work fine for old kernels that don't
have a clue about the new system call interfaces.
WITHOUT any new magic system calls.
WITHOUT any stupid SIGSEGV tricks.
WITHOUT and silly mmap()'s on magic files.
> My point was that the double-mapped page trick adds no overhead in the
> case of a static binary, and just one extra mmap in case of a shared
> binary.
For _zero_ gain. The jump to the library address has to be indirect
anyway, and glibc has several places to put the information without any
mmap's or anything like that.
Linus
^ permalink raw reply
* RFC: bus_type and device_class merge (or partial merge)
From: Adam J. Richter @ 2002-12-19 19:36 UTC (permalink / raw)
To: mochel; +Cc: linux-kernel
If there is a more specific mailing list than lkml for discussing
the generic driver model, please feel free to redirect me.
I'm thinking about trying to embed struct device_class into
struct bus_type or perhaps just eliminate the separate struct
bus_type. The two structures are almost identical, especially
considering that device_class.devnum appears not to be used by
anything.
struct bus_type {
char * name;
struct subsystem subsys;
struct subsystem drvsubsys;
struct subsystem devsubsys;
struct list_head devices;
struct list_head drivers;
int (*match)(struct device * dev, struct device_driver * drv);
struct device * (*add) (struct device * parent, char * bus_id);
int (*hotplug) (struct device *dev, char **envp,
int num_envp, char *buffer, int buffer_size);
};
struct device_class {
char * name;
u32 devnum;
struct subsystem subsys;
struct subsystem devsubsys;
struct subsystem drvsubsys;
struct list_head drivers;
struct list_head devices;
int (*add_device)(struct device *);
void (*remove_device)(struct device *);
int (*hotplug)(struct device *dev, char **envp,
int num_envp, char *buffer, int buffer_size);
};
At first appearance, a bus_type (PCI, USB, etc.) and a
device_class (network devices, input, block devices), may seem like
opposite ends of the device driver abstraction, but really I think
these are basically the same, and, more importantly, there can be many
layers of these interfaces, and the decision about which are bus_types
and which are device_classes is causing unnecessary coplexity. For
example, SCSI defines both. SCSI can be a hardware bus, bus it also
needs device_class so that scsi_debug (and eventually scsi generic) can
use the struct interface mechanism.
If you look at the five places where a struct device_class is
actually defined in 2.5.52, you'll see that either the device_class is
not referenced by anything else or it has no bus type. So, there
seems to be little use of the distinction.
device_class variable Referenced elsewhere? bus_type?
cpu_devclass No system_bus_type
memblk_devclass No system_bus_type
node_devclass No system_bus_type
input_devclass Yes (mousedev, tsdev) (None)
shost_devclass Yes (scsi_debug) (None)
Also, merging device_class and bus_type could also enable a
little more consolidation between struct device_interface and struct
device_driver (as with device_class.devnum, device_interface.devnum
does not appear to be used currently).
Anyhow, I think this could shrink the drivers/base a bit and
make it slightly more understandable. I'd be interested in knowing if
anyone else is contemplating or developing this or wants to point out
issues to watch out for.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
^ permalink raw reply
* Re: How can I expand the window size of a telnet session?
From: Ray Olszewski @ 2002-12-19 19:27 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <att5ra$if3$1@main.gmane.org>
At 02:15 PM 12/19/02 -0500, Jamie Risk wrote:
>[...]
> > "X client"? X is a server; client applications use it. And I'm assuming
> > below that "windows" refers to some version of Microsoft Windows.
>
>ummm, I've been fiddling with XWin32, which I thought was X windows
>manager that operated as a "client" logging into my Linux X-Windows
>"server".
I'm unfamiliar with that product, but a quick search found its home Web
site at http://www.xwin32.dk/, and the docs there refer to it as a "PC X
server". So I assume it is a fairly conventional implementation of X for
Windows (there have been many over the years). With no details provided, it
is not apparent why it is not working for you ... but to the extent that
the problems are on the Windows end, this list is not likely to be a good
place to work those out.
Another option you might want to consider is VNC. To use it, you run a
server on the remote machine (in this case, the Linux host) and a client on
the local workstation (in this case, the WinXX host). Your Linux distro
probably have both vncserver and vncclient packages, and the usual sorts of
searches will lead you to the Windows app.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-19 19:29 UTC (permalink / raw)
To: bart
Cc: torvalds, lk, terje.eggestad, drepper, matti.aarnio, hugh, davej,
mingo, linux-kernel
In-Reply-To: <20021219132239.4650B51F88@gum12.etpnet.phys.tue.nl>
bart@etpmod.phys.tue.nl wrote:
> On 18 Dec, Linus Torvalds wrote:
>
>>On Wed, 18 Dec 2002, Jamie Lokier wrote:
>>
>>>That said, you always need the page at 0xfffe0000 mapped anyway, so
>>>that sysexit can jump to a fixed address (which is fastest).
>>
>>Yes. This is important. There _needs_ to be some fixed address at least as
>>far as the kernel is concerned (it might move around between reboots or
>>something like that, but it needs to be something the kernel knows about
>>intimately and doesn't need lots of dynamic lookup).
>>
>>However, there's another issue, namely process startup cost. I personally
>>want it to be as light as at all possible. I hate doing an "strace" on
>>user processes and seeing tons and tons of crapola showing up. Just for
>
> So why not map the magic page at 0xffffe000 at some other address as
> well?
>
> Static binaries can just directly jump/call into the magic page.
>
> Shared binaries do somekind of mmap("/proc/self/mem") magic to put a
> copy of the page at an address that is convenient for them. Shared
> binaries have to do a lot of mmap-ing anyway, so the overhead should be
> negligible.
>
That would require /proc to be mounted for all shared binaries to work.
That is tantamount to killing chroot().
Perhaps it could be done with mremap(), but I would assume that would
entail a special case in the mremap() code.
A special system call would be a bit gross, but it's better than a total
hack.
-hpa
^ permalink raw reply
* [RELEASE] Ipsysctl-tutorial 1.0.2
From: Oskar Andreasson @ 2002-12-19 19:20 UTC (permalink / raw)
To: lartc, netfilter
Ok, sorry about sending all these notifications, but this is the last
notification for a couple of weeks, so please don't flame me:).
I just decided to release version 1.0.2 of the ipsysctl tutorial, and it
is now up at http://ipsysctl-tutorial.frozentux.net
This version is seriously broken, and a lot of stuff is still missing, but
there has been so many minor fixes etc, and long time since the last
release, that I decided to release it now anyway. Also, I will be gone for
2 weeks (I think you call it "extended animation" in english... I will be
up in the dark dark _dark_ side of Sweden, probably sleeping the whole
time;)), hence this release at this time.
Special thanks to Don Cohen for going through the icmp_rate* variables
over and over and over with me... Sometimes I just don't get the text
right, which I think he has proven.
Thanks all!
--
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [LARTC] [RELEASE] Ipsysctl-tutorial 1.0.2
From: Oskar Andreasson @ 2002-12-19 19:20 UTC (permalink / raw)
To: lartc
Ok, sorry about sending all these notifications, but this is the last
notification for a couple of weeks, so please don't flame me:).
I just decided to release version 1.0.2 of the ipsysctl tutorial, and it
is now up at http://ipsysctl-tutorial.frozentux.net
This version is seriously broken, and a lot of stuff is still missing, but
there has been so many minor fixes etc, and long time since the last
release, that I decided to release it now anyway. Also, I will be gone for
2 weeks (I think you call it "extended animation" in english... I will be
up in the dark dark _dark_ side of Sweden, probably sleeping the whole
time;)), hence this release at this time.
Special thanks to Don Cohen for going through the icmp_rate* variables
over and over and over with me... Sometimes I just don't get the text
right, which I think he has proven.
Thanks all!
--
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [ANNOUNCE] 2.5.52-lsm1
From: Chris Wright @ 2002-12-19 19:25 UTC (permalink / raw)
To: William Lee Irwin III, linux-security-module, linux-kernel
In-Reply-To: <20021219111433.GM1922@holomorphy.com>
* William Lee Irwin III (wli@holomorphy.com) wrote:
>
> Forgive my ignorance (if this applies) but I recently submitted a patch
> acked by both you and gregkh. If there are difficulties with it I'd be
> much obliged to hear of them and will resolve them with the utmost
> urgency. Aside from that my only concern is that it did not appear in
> your changelog. If it's been deferred to a later push that is also okay
> with me.
As you already noted, Greg has pushed that change to Linus in a separate
patchset.
cheers,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: Hammerfall configuration
From: patrick reardon @ 2002-12-19 19:15 UTC (permalink / raw)
To: Paul Davis
Cc: alsa-devel@lists.sourceforge.net, alsa-user@lists.sourceforge.net
In-Reply-To: <200212190924.18p4pc1V73NZFji0@eagle>
it works! disks burn correctly now. thanks to everyone who helped me get this
straightened out, especially paul davis and joerg shilling. in case it might help someone
else, i'm running a redhat based system and load the hammerfall modules at boot time with
this line added to /etc/rc.d/rc.sysinit:
action "Loading ALSA Hammerfall driver" modprobe snd-rme9652
/etc/modules.conf is set to load soundcore and snd-rme9652-mem before snd-rme9652, so this
takes care of it. to automatically set the hammerfall's internal clock as master (or use
any non-default configuration) , the line
action "Setting Hammerfall as master clock" alsactl restore snd-rme9652
can be added after the modprobe command.
patrick
Paul Davis wrote:
>
> >by hand, changing the 'Sync Mode' value from AutoSync to Master
> >(should these values be in quotes?), ran "alsactl store hammerfall",
> >unloaded then reloaded the alsa m odules, then ran "alsactl restore
> >hammerfall. ("hammerfall" is the card's id.) but asound .state
> >still indicates Sync Mode is set to AutoSync. "vi
> >/proc/asound/hammerfall/rme 9652" reads
>
> you got the process wrong.
>
> 1) alsactl store hammerfall
> 2) edit file
> 3) alsactl restore hammerfall
>
> no driver unload/load is needed. each time you reload the module
> without the 3rd step, you get back to the driver's own default
> settings.
>
> >i'm also curious if the "IEC958 sample rate: error flag set" is normal and if
> >not, what to
> >look at to fix it. asound.state says
>
> it means you have no s/pdif input.
>
> --p
-------------------------------------------------------
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: How can I expand the window size of a telnet session?
From: Jamie Risk @ 2002-12-19 19:15 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <5.1.0.14.1.20021219083029.020b4840@celine>
"Ray Olszewski" <ray@comarre.com> wrote in message
news:5.1.0.14.1.20021219083029.020b4840@celine...
> At 10:27 AM 12/19/02 -0500, Jamie Risk wrote:
> >I've given up getting an XTerm session from my windows X
> >client working, and really all I want is large text window session.
>
> "X client"? X is a server; client applications use it. And I'm assuming
> below that "windows" refers to some version of Microsoft Windows.
>
ummm, I've been fiddling with XWin32, which I thought was X windows
manager that operated as a "client" logging into my Linux X-Windows
"server".
> No doubt a search of a Windows freeware/shareware archive like
> TUCOWS will turn up some other choices.
Thanks, I will.
- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [RELEASE] Iptables tutorial 1.1.16
From: Oskar Andreasson @ 2002-12-19 19:10 UTC (permalink / raw)
To: lartc, netfilter
Hi all,
This is a rather late notification about the fact that the iptables
tutorial was released in version 1.1.16 three days ago. No big changes
from 1.1.15, except tons of internal fixes since I moved from Red Hat to
Debian on my main workstation. This caused a hole lot of problems for
mirrors etc, but it should now be fixed again.
As always, available at http://iptables-tutorial.frozentux.net
Thanks, and sorry for disturbing all threads.
--
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ 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.