* Re: 2.5.51 ide module problem
From: Jeff Chua @ 2002-12-11 7:07 UTC (permalink / raw)
To: Adam J. Richter; +Cc: jchua, linux-kernel
In-Reply-To: <200212110650.WAA13780@adam.yggdrasil.com>
On Tue, 10 Dec 2002, Adam J. Richter wrote:
> >depmod will ecounter "Segmentation fault" if the ide.ko and ide-io.ps
> >modules are in /lib/modules/2.5.51/kernel
>
> I think the new depmod recurses infinitely when it encounters
> circular dependencies. It eventually segfaults and leaves a huge
> modules.dep file from the infinite loop. If you look at the final
> huge line in that file, you can see where the loop occurred.
>
> depmod has no need to do any recursion, since it only needs
> to determine the immediate dependencies of each module. However,
> noticing such loops and printing them out would be a handy feature.
>
> I use IDE as a module, but I had to change the Makefile to
> build a big ide-mod.o from most of the core objects rather than
> allowing each one to be its own module. I believe I posted IDE
> modularization patches at least once a couple of months ago, but it
> seems to have fallen between the cracks. I could repost it if need
> be
Yes, please, send me your patch. I hope this patch works for
module-init-tools-0.9.3
>, although I have not yet booted 2.5.51.
I had same problem with pre 2.5.51. With 2.5.51, kernel now boot and I'm
able to get login prompt using ramdisk. Only catch is I've to specify
root=/dev/ram0 instead of /dev/ram for it to boot.
Thanks,
Jeff.
>
> Also note that I have not used the in kernel-based module
> loader recently, as I have been patching my kernels to use the user
> level module code. I am planning to try the kernel-base module loader
> in 2.5.51 once I fix other problems it has finding the root device
> under devfs. So, it's remotely possible that you may also see module
> problems that I've missed.
>
> 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: [PATCH] compatibility syscall layer (lets try again)
From: Daniel Jacobowitz @ 2002-12-11 7:10 UTC (permalink / raw)
To: george anzinger
Cc: Linus Torvalds, Jim Houston, Stephen Rothwell, LKML, anton,
David S. Miller, ak, davidm, schwidefsky, ralf, willy
In-Reply-To: <3DF673B9.4E273E83@mvista.com>
On Tue, Dec 10, 2002 at 03:07:37PM -0800, george anzinger wrote:
> Daniel Jacobowitz wrote:
> >
> > On Fri, Dec 06, 2002 at 09:57:08AM -0800, Linus Torvalds wrote:
> > >
> > > I just pushed my version of the system call restart code to the BK trees.
> > > It's losely based on Georges code, but subtly different. Also, I didn't
> > > actually update any actual system calls to use it, I just did the
> > > infrastructure.
> > >
> > > Non-x86 architectures need to be updated to work with this: they need to
> > > update their thread structures, the additional do_signal() support in
> > > their signal.c, and add the actual system call itself somewhere. For x86,
> > > this was about 15 lines of changes.
> > >
> > > The basic premise is very simple: if you want to restart a system call,
> > > you can do
> > >
> > > restart = ¤t_thread()->restart_block;
> > > restart->fn = my_continuation_function;
> > > restart->arg0 = my_arg0_for_continuation;
> > > restart->arg1 = my_arg1_for_continuation;
> > > ..
> > > return -ERESTARTSYS_RESTARTBLOCK;
> > >
> > > which will cause the system call to either return -EINTR (if a signal
> > > handler was actually invoced) or for "benign" signals (SIGSTOP etc) it
> > > will end up restarting the system call at the continuation function (with
> > > the "restart" block as the argument).
> > >
> > > We could extend this to allow restarting even over signal handlers, but
> > > that would have some re-entrancy issues (ie what happens if a signal
> > > handler itself wants to use a system call that may want restarting), so at
> > > least for now restarting is only done when no handler is invoced (*).
> > >
> > > Linus
> > >
> > > (*) The nesting case is by no means impossible to handle gracefully
> > > (adding a "restart even if handler is called" error number and returning
> > > -EINTR if nesting, for example), but I don't know of any system calls that
> > > would really want to try to restart anyway, so..
> >
> > Well, here's something to consider. This isn't entirely hypothetical;
> > there are test cases in GDB's regression suite that cover nearly this.
> >
> > Suppose a process is sleeping for an hour. The user wants to see what
> > another thread is doing, so he hits Control-C; the thread which happens
> > to be reported as 'current' is the one that was in nanosleep(). It
> > used to be that when he said continue, the nanosleep would return; now
> > hopefully it'll continue. Great! But this damnable user isn't done
> > yet. He wants to look at one of his data structures. He calls a
> > debugging print_foo() function from GDB. He realizes he left a
> > sleep-for-a-minute nanosleep call in it and C-c's again. Now we have
> > two interrupted nanosleep calls and the application will never see a
> > signal to interrupt either of them; he says "continue" twice and
> > expects to get back to his hour-long sleep.
> >
> > Note that I'm not saying we _need_ to support this, mind :) It's a
> > little pathological.
>
> I seem to recall working on a debugger in the distant past
> and put a lock in it that did not allow it to run a debuggee
> function while the debugee was in a system call. It seems
> to me that is is begging for problems and is not that hard
> for gdb/etc to prevent.
>
> Daniel, what to you think?
I really don't see the point. I like being able to call functions
while stopped in read() or poll(); you can hit C-c and go off to
examine your application. That's as much "in a syscall" as this is.
Besides, implementing this is more of a pain than it's worth.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* disallow normal users from bind()-ing to ports
From: David Garamond @ 2002-12-11 7:03 UTC (permalink / raw)
To: netfilter
hi,
i want to regulate local users on our non-firewalled machines:
+ normal, non-system users (uid >= 500) shall not be able to bind to any
port (so that they cannot run file-sharing applications, bypass company
proxies/mailservers and what not);
+ there are certain IP aliases (say: 12.34.56.78 and 12.34.56.79) and of
course 0.0.0.0 that should be able to be bind()-ed by normal users at all.
seeing that iptables now has --*-owner options, is it possible to
achieve this goal with iptables? or do i still have to trap the bind()
(or accept(), or listen()) syscall somehow?
--
dave
^ permalink raw reply
* RE: boot sequence
From: Ray Olszewski @ 2002-12-11 7:11 UTC (permalink / raw)
To: Joseph D. Wagner, 'linux-newbie'
In-Reply-To: <000d01c2a0de$c2b9de20$972a3a41@joe>
Joseph -- I think you may have gotten this list mixed up with some other
list that you subscribe to. This list (linux-newbie) is a list for Linux
beginners to ask general questions on, NOT a list for Linux kernel
questions (at least, not exclusively). While I don't know Mandrake so
cannot myself answer Dave's original question, it is hardly inappropriate
for a beginner's list.
At 12:30 AM 12/11/02 -0600, Joseph D. Wagner wrote:
>This is a discussion for a Mandrake mailing list, not the Linux kernel.
>
>-----Original Message-----
>From: linux-newbie-owner@vger.kernel.org
>[mailto:linux-newbie-owner@vger.kernel.org] On Behalf Of dave
>Sent: Tuesday, December 10, 2002 1:57 PM
>To: linux-newbie
>Subject: boot sequence
>
>I'm having a problem with MySQL starting on boot and I don't quit understand
>
>the boot sequence of Mandrake 9.0. What files get executed and where they
>are located. Anyone have a link to a writeup about this? Thanks for your
>time.
>Dave Pomeroy K7DNP SouthWestern Washington
--
-------------------------------------------"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: "bio too big" error
From: Jens Axboe @ 2002-12-11 7:21 UTC (permalink / raw)
To: Wil Reichert; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <1039577938.388.9.camel@darwin>
On Tue, Dec 10 2002, Wil Reichert wrote:
> Exact error with debug is:
>
> darwin:/a01/mp3s/Skinny Puppy/Too Dark Park# ogg123 -q 01\ -\
> Convulsion.ogg
> bio too big device ide0(3,4) (256 > 255)
looks like a one-off in the dm merge_bvec function.
--
Jens Axboe
^ permalink raw reply
* RE: boot sequence
From: Joseph D. Wagner @ 2002-12-11 7:19 UTC (permalink / raw)
To: 'Ray Olszewski', dave; +Cc: 'linux-newbie'
In-Reply-To: <5.1.0.14.1.20021210230856.020c62a0@celine>
> Joseph -- I think you may have gotten this list
> mixed up with some other list that you subscribe
> to. This list (linux-newbie) is a list for Linux
> beginners to ask general questions on, NOT a list
> for Linux kernel questions (at least, not exclusively).
Yeah, but Dave CC'ed that list too.
> While I don't know Mandrake so cannot myself answer
> Dave's original question, it is hardly inappropriate
> for a beginner's list.
That's just my point. His question is about a specific distribution of
Linux -- Mandrake. That's too specific for this list. I'm not saying it's
inappropriate; I'm just saying he'd get a better response from a list
specifically designed for Mandrake Linux, rather than posting to a general
Linux list.
Joseph Wagner
-
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: [Linux-ia64] unalinged access by loadpair instruction
From: Hideki Yamamoto @ 2002-12-11 7:26 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805518@msgid-missing>
Hi David,
I have just confirmed if the kernel applied the patch
you sent.
It works fine.
Thank you so much.
End of my email
--
Yours faithfully,
Hideki Yamamoto (V).v.(V) # Empowered by Innovation
At Mon, 9 Dec 2002 18:33:38 -0800,
David Mosberger wrote:
>
> >>>>> On Mon, 9 Dec 2002 14:59:30 -0800, "Luck, Tony" <tony.luck@intel.com> said:
>
> Tony> You do recall correctly ... checking the archives, I posted a
> Tony> patch on October 16, 2001. I did fix the floating point case
> Tony> back then too ... in fact my post claims to include the patch
> Tony> for both integer and FP. But I must have attached the wrong
> Tony> patch file. I've long since deleted all my 2.4.10 trees, so
> Tony> I'd have to reconstruct from scratch (can't do it from memory,
> Tony> those neurons have been re-assigned :-(
>
> OK, it looks like the fix is pretty straight-forward. The patch below
> _should_ work, though I haven't tested it extensively.
>
> Hideki, can you try it out? BTW: I think your test program is buggy.
> The core-loop isn't right because br.ctop renames by one register
> position, not two. I attached a version of the test program which
> does what you wanted.
>
> --david
>
> === arch/ia64/kernel/unaligned.c 1.6 vs edited ==> --- 1.6/arch/ia64/kernel/unaligned.c Thu Mar 14 00:28:41 2002
> +++ edited/arch/ia64/kernel/unaligned.c Mon Dec 9 18:24:54 2002
> @@ -486,7 +486,21 @@
> DPRINT("*0x%lx=0x%lx NaT=%d new unat: %p=%lx\n", addr, val, nat, (void *) unat,*unat);
> }
>
> -#define IA64_FPH_OFFS(r) (r - IA64_FIRST_ROTATING_FR)
> +/*
> + * Return the (rotated) index for floating point register REGNUM (REGNUM must be in the
> + * range from 32-127, result is in the range from 0-95.
> + */
> +static inline unsigned long
> +fph_index (struct pt_regs *regs, long regnum)
> +{
> + unsigned long rrb_fr = (regs->cr_ifs >> 25) & 0x7f;
> +
> + regnum -= IA64_FIRST_ROTATING_FR;
> + regnum += rrb_fr;
> + if (regnum >= 96)
> + regnum -= 96;
> + return regnum;
> +}
>
> static void
> setfpreg (unsigned long regnum, struct ia64_fpreg *fpval, struct pt_regs *regs)
> @@ -507,7 +521,7 @@
> */
> if (regnum >= IA64_FIRST_ROTATING_FR) {
> ia64_sync_fph(current);
> - current->thread.fph[IA64_FPH_OFFS(regnum)] = *fpval;
> + current->thread.fph[fph_index(regs, regnum)] = *fpval;
> } else {
> /*
> * pt_regs or switch_stack ?
> @@ -566,7 +580,7 @@
> */
> if (regnum >= IA64_FIRST_ROTATING_FR) {
> ia64_flush_fph(current);
> - *fpval = current->thread.fph[IA64_FPH_OFFS(regnum)];
> + *fpval = current->thread.fph[fph_index(regs, regnum)];
> } else {
> /*
> * f0 = 0.0, f1= 1.0. Those registers are constant and are thus
> ----------------------------------------------------
> #define n 100
>
> double d[n],d2[n+1];
>
> main() {
> int i,j;
>
> for (i = 0; i < n; i++) {
> d[i] = i;
> d2[i] = 0.0;
> }
> copy_by_loadpair(&d, &d2, n/2-1);
> for (i = 0; i < n; i++) {
> if (d2[i] != i)
> printf("d2[%d] = %f, should be d[%d]=%f\n",
> i, d2[i], i, d[i]);
> }
> }
>
> ----------------------------------------------------
> .file "a.c"
> .pred.safe_across_calls p1-p5,p16-p63
> .text
> .align 16
> .global copy_by_loadpair
> .proc copy_by_loadpair
> copy_by_loadpair:
> alloc r8=ar.pfs,3,6,0,0 ;;
> mov r15=r32
> mov r2=r33
> add r3=8,r33
> mov ar.lc=r34
> mov pr.rot=0x10000
> mov ar.ec=5 ;;
> L1:
> (p16) ldfpd f32,f37=[r15],16
> (p20) stfd [r2]ó6,16
> (p20) stfd [r3]ô1,16
> br.ctop.sptk L1;;
> br.ret.sptk.many b0 ;;
> .endp get_by_loadpair
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
^ permalink raw reply
* Re: "get_cnode failed" error
From: Oleg Drokin @ 2002-12-11 7:26 UTC (permalink / raw)
To: Alexandre Ratti; +Cc: reiserfs-list, mason
In-Reply-To: <4.3.2.7.2.20021210125742.00b96f60@mail.poulpe.net>
Hello!
On Tue, Dec 10, 2002 at 08:55:08PM +0100, Alexandre Ratti wrote:
> The FS looks OK, but I'm curious. What does this error mean? It is serious?
This error means there was some journaling code screwup. So FS panicked
before it could do any harm to on-disk data.
What does your script does with cp? Do you have at least some aproximate ideas
on what it copied and from where to where?
> Dec 10 00:18:39 p120 kernel: <0>get_cnode failed!
> Dec 10 00:18:40 p120 kernel: invalid operand: 0000
> Dec 10 00:18:40 p120 kernel: CPU: 0
> Dec 10 00:18:40 p120 kernel: EIP: 0010:[reiserfs_panic+41/88] Not
> tainted
> Dec 10 00:18:40 p120 kernel: EFLAGS: 00010282
> Dec 10 00:18:40 p120 kernel: eax: 00000015 ebx: c0215ada ecx:
> c087e000 edx: c118da80
> Dec 10 00:18:40 p120 kernel: esi: c13be000 edi: 00000000 ebp:
> c13be000 esp: c087fe30
> Dec 10 00:18:40 p120 kernel: ds: 0018 es: 0018 ss: 0018
> Dec 10 00:18:40 p120 kernel: Process cp (pid: 7360, stackpage=c087f000)
> Dec 10 00:18:40 p120 kernel: Stack: c0212f5a c02909e0 c0215ada c087fe54
> c087ff2c c20d7140 c01813d9 c13be000
> Dec 10 00:18:40 p120 kernel: c0215ada 0141411a c20d7140 c087fe98
> c087ff08 c016cfb0 ffffffff 00000000
> Dec 10 00:18:40 p120 kernel: c016d11b c087ff2c c13be000 c20d7140
> c087feb0 c0392460 c0392460 c087ff2c
> Dec 10 00:18:40 p120 kernel: Call Trace: [journal_mark_dirty+501/772]
> [update_st at_data+224/232] [reiserfs_update_sd+355/380]
> [reiserfs_link+199/256] [vfs_link+137/188]
> Dec 10 00:18:41 p120 kernel: [sys_link+212/308] [sys_lstat64+100/112]
> [system_call+51/64]
> Dec 10 00:18:41 p120 kernel:
> Dec 10 00:18:41 p120 kernel: Code: 0f 0b 68 e0 09 29 c0 85 f6 74 11 31 c0
> 66 8b 46 08 50 e8 88
Bye,
Oleg
^ permalink raw reply
* RE: config.h
From: Joseph D. Wagner @ 2002-12-11 7:28 UTC (permalink / raw)
To: 'Chuck Winters', linux-c-programming
In-Reply-To: <20021210155618.A11637@atl.lmco.com>
> Would it be prudent to include the linux/config.h
> file in a user level program to check for the
> existence of certain modules? I know there are
> other ways, like using autoconf, etc. I was just wondering.
No, because modules can be dynamically loaded on-the-fly, completely
independent of however the kernel is compiled.
Additionally, config.h (actually just an #include for autoconfig.h) is an
automatically generated file which varies depending upon how an INDIVIDUAL
USER compiles his/her own INDIVIDUAL kernel. There's no way for you to
anticipate the contents of config.h in advance. It's better to use other
methods.
Use of config.h would be necessary if you were compiling something directly
into the kernel.
Joseph Wagner
^ permalink raw reply
* RE: portfw on iptables 2.4 kernel problem.
From: Reckhard, Tobias @ 2002-12-11 7:32 UTC (permalink / raw)
To: netfilter
Hi
I'm not entirely sure what you want to do, but here goes.
> I have an internel ftp server w/c i want to access over my
> linux router(gw)
> Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> 203.100.100.1.
> I followed the docs w/c i found at linuxdoc
> http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
> I type in this iptables rule set,
>
> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
> 10.0.0.11:21
>
> I enabled ip forwarding thru the kernel by typing this
> command, (this is the
> first thing i type then the iptables rule set)
>
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> svr:/# cat /proc/sys/net/ipv4/ip_forward
> 1
> svr:/#
>
> And still it does not work..
>
> Trying 203.100.100.1...
> telnet: Unable to connect to remote host: Connection refused
I expect you're trying to access the FTP server on 10.0.0.11 from the
Internet by redirecting connections to the firewall's external IP address
(203.100.100.1) to the FTP server.
I haven't dealt with D/SNATing FTP yet and it's one of the more complicated
protocols to do this for (and it's a horrible protocol anyway, so you should
avoid it entirely if you can), but I believe you need to do the following:
Prerequisites:
1. Load the FTP conntrack and FTP NAT modules (maybe the basic conntrack
module as well), enable IP forwarding.
Take care of the FTP control connection:
2. Permit INPUT on the outside interface of the firewall to TCP port 21 with
states NEW and ESTABLISHED
3. Permit OUTPUT on the outside interface of the firewall from TCP port 21
with state ESTABLISHED
4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
203.100.100.1 --dport 21" (see point 2 above) to the internal server at
10.0.0.11.
5. Permit FORWARDing of those same packets with states NEW and ESTABLISHED.
6. Permit FORWARDing of response packets ("-s 10.0.0.11 --sport 21") with
state ESTABLISHED.
The FTP data connection:
a) Active FTP:
7. Permit FORWARDing from the internal server, TCP source port 20, with
states ESTABLISHED and RELATED.
8. Permit FORWARDing to the internal server, TCP destination port 20, with
state ESTABLISHED.
9. Permit OUTPUT from the firewall's outside interface (and source IP
address), TCP source port 20, with states ESTABLISHED and RELATED.
10. Permit INPUT on the firewall's outside interface (and IP), TCP
destination port 20, state ESTABLISHED.
You may also need to SNAT the outbound packets to the firewall's outside IP
address in the POSTROUTING chain.
b) Passive FTP:
11. Permit INPUT on the firewall's outside interface (and IP), TCP
destination port 1024-65535, states ESTABLISHED and RELATED
12. PREROUTING DNAT those packets to the internal server.
13. FORWARD them with states ESTABLISHED and RELATED
14. FORWARD the ESTABLISHED return packets
15. OUTPUT the ESTABLISHED return packets.
Check to see if that works. Add a catch-all logging rule to the end of all
chains you use and see if it gets hit by anything when debugging.
Cheers
Tobias
^ permalink raw reply
* Raid 5 on 2.5.50/2.5.51, dirty array, kernel panic
From: Eurijk @ 2002-12-11 7:34 UTC (permalink / raw)
To: linux-raid
I set up an IDE raid array as such:
/dev/md1 hda1 hdc1 hde1 hdg1 RAID 1
/dev/md0 hda2 hdc2 hde2 hdg2 RAID 5
Installed slack, set up lilo, and waited for rebuilding to finish.
Now to simulate a failure I shut it down and physically unhooked
(**boom hellfire fury**! :D) /dev/hda. From everything I understand,
the system should work just fine still.
Bios detects hdc is still there, and auto boots off that. Kernel loads,
good lilo did it's job :D, but...:
...
md: created md0
...
md: running: <hdg2><hde2><hdc2>
md: md0: raid array is not clean -- starting background reconstuction
...
raid5: device hdg2 operational as raid disk 3
raid5: device hde2 operational as raid disk 2
raid5: device hdc2 operational as raid disk 1
raid5: cannot start dirty degraded array for md0
RAID5 conf printout:
--- rd:4 wd:3 fd:1
disk 1, o:1, dev:hdc2
disk 2, o:1, dev:hde2
disk 3, o:1, dev:hdg2
raid5: failed to run raid set md0
md: pers->run() failed ...
md :do_md_run() returned -22
md: md0 still in use.
...
raid1: raid set md1 active with 3 out of 4 mirrors
...
md: ... autorun DONE.
Unable to handle kernel NULL pointer dereference at virtual address 00000088
printing eip:
c0289977
(stack/register dump is here :D)
...
<0>Kernel panic: Attempted to kill init!
The "cannot start dirty degraded array" was added in 2.5.34 I believe. I can't
test a pre 2.5.34 since my 20271 was added in 2.5.37. >;-) I can test it using
good ol' hda/hdb/hdc/hdd if it would be of some help.
Let me know if I'm off my rocker!
Thanks
-eurijk!
^ permalink raw reply
* Re: [PATCH] epoll: don't printk pointer value
From: William Lee Irwin III @ 2002-12-11 7:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Robert Love, davidel, linux-kernel
In-Reply-To: <3DF6DE1A.6FD498C9@digeo.com>
Robert Love wrote:
>> ...
On Tue, Dec 10, 2002 at 10:41:30PM -0800, Andrew Morton wrote:
> Guys, it's noise. Just nuke it.
Fine by me. I just notice the format string business.
Bill
^ permalink raw reply
* problems with ALSA
From: r4mz3z @ 2002-12-11 7:49 UTC (permalink / raw)
To: linux-newbie
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi friends...
I have a VIA sound card and I've supossed ALSA drivers can give sound... I
follow the instructions but when (been root) run modprobe receive an error...
just like this:
- -------------------------------------------------------------
[root@localhost root]# modprobe snd-via82xx
/lib/modules/.../snd.o: unresolved symbol __get_free_pages_Rsmp_4784e424
/lib/modules/.../snd.o: unresolved symbol try_inc_mod_count_Rsmp_e6105b23
/lib/modules/.../snd.o: unresolved symbol fasync_helper_Rsmp_0f820065
/lib/modules/.../snd.o: unresolved symbol strstr_Rsmp_1e6d26a8
/lib/modules/.../snd.o: unresolved symbol isa_dma_bridge_buggy_Rsmp_f82abc1d
/lib/modules/.../snd.o: unresolved symbol remove_proc_entry_Rsmp_18199406
/lib/modules/.../snd.o: unresolved symbol __write_lock_failed
/lib/modules/.../snd.o: unresolved symbol kill_fasync_Rsmp_f866c12a
/lib/modules/.../snd.o: unresolved symbol _ctype_Rsmp_8d3894f2
/lib/modules/.../snd.o: unresolved symbol request_module_Rsmp_27e4dc04
/lib/modules/.../snd.o: unresolved symbol proc_root_Rsmp_c79b35f0
/lib/modules/.../snd.o: unresolved symbol register_chrdev_Rsmp_10735b95
/lib/modules/.../snd.o: unresolved symbol create_proc_entry_Rsmp_9cfe096c
/lib/modules/.../snd.o: unresolved symbol __generic_copy_to_user_Rsmp_d523fdd3
/lib/modules/.../snd.o: unresolved symbol pci_alloc_consistent_Rsmp_d2217097
/lib/modules/.../snd.o: unresolved symbol vsnprintf_Rsmp_57a6504e
/lib/modules/.../snd.o: unresolved symbol unregister_chrdev_Rsmp_c192d491
/lib/modules/.../snd.o: unresolved symbol dma_spin_lock_Rsmp_375c41f8
/lib/modules/.../snd.o: unresolved symbol __vmalloc_Rsmp_79995c5b
/lib/modules/./snd.o: unresolved symbol unregister_sound_special_Rsmp_99c95fa5
/lib/modules/.../snd.o: unresolved symbol sprintf_Rsmp_1d26aa98
/lib/modules/.../snd.o: unresolved symbol schedule_timeout_Rsmp_17d59d01
/lib/modules/.../snd.o: unresolved symbol __read_lock_failed
/lib/modules/.../snd.o: unresolved symbol __wake_up_Rsmp_127fda83
/lib/modules/.../snd.o: unresolved symbol register_sound_special_Rsmp_3a650025
/lib/modules/.../snd.o: unresolved symbol printk_Rsmp_1b7d4074
/lib/modules/.../snd.o: unresolved symbol kfree_Rsmp_037a0cba
/lib/modules/.../snd.o: unresolved symbol free_pages_Rsmp_9941ccb8
/lib/modules/.../snd.o: unresolved symbol vfs_readlink_Rsmp_6502d84f
/lib/modules/.../snd.o: unresolved symbol vfree_Rsmp_2fd1d81c
/lib/modules/.../snd.o: unresolved symbol mem_map_Rsmp_ed75ce01
/lib/modules/.../snd.o: unresolved symbol vfs_follow_link_Rsmp_9b5fde49
/lib/modules/.../snd.o: unresolved symbol kmalloc_Rsmp_93d4cfe6
/lib/modules/.../snd.o: unresolved symbol schedule_Rsmp_4292364c
/lib/modules/.../snd.o: unresolved symbol remove_wait_queue_Rsmp_ca8842ea
/lib/modules/.../snd.o: unresolved symbol pci_free_consistent_Rsmp_4a863b05
/lib/modules/./snd.o: unresolved symbol __generic_copy_from_user_Rsmp_116166aa
/lib/modules/.../snd.o: unresolved symbol system_utsname_Rsmp_b12cdfe7
/lib/modules/.../snd.o: unresolved symbol add_wait_queue_Rsmp_2fd0ca84
/lib/modules/.../snd.o: unresolved symbol __pollwait_Rsmp_4c541ea9
/lib/modules/2.4.18-3/kernel/drivers/sound/snd.o: insmod
/lib/modules/2.4.18-3/kernel/drivers/sound/snd.o failed
/lib/modules/2.4.18-3/kernel/drivers/sound/snd.o: insmod snd-via82xx failed
[root@localhost root]#
- -------------------------------------------------------------
The path complete is: /lib/modules/2.4.18-3/kernel/drivers/sound/
I'm using RedHat 7.3.
Please help me; thanh you very much
- --
Linux User Registered #232544
my GnuPG-key at www.keyserver.net
--- rm -rf /bin/laden ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE99u4us4dF9gl05swRAnmcAJ9k4FFmunJ+Ut+b2AFyXTEPZ9yurACggzSc
hU4s0pK6xxGhhT859Qdw4i8=
=kd/A
-----END PGP SIGNATURE-----
-
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
* mounting udf DVD-RAM changes owner
From: TomF @ 2002-12-11 8:00 UTC (permalink / raw)
To: linux-kernel
I am running Redhat 8.0 plus Win4Lin 4.0.7 on a Pentium III 600Mhz with 768MB RAM, 4 SCSI hard drives, an IDE hard drive, a Panasonic LF-D201 SCSI DVD-RAM, an HP deskjet 6122, and an HP Scanjet 7450C. The Redhat kernel is 2.4.18-14, and the Win4Lin kernel is a patched version of the Redhat kernel. I have DVD-RAM cartridges formatted FAT32 under Windows XP, and others formatted by udftools-1.0.0b2/mkudffs. The fstab entry of interest is
/dev/scd0 /mnt/dvd auto noauto,users,kudzu,rw,exec,uid=Tom,umask=000 0 0
Before I mount a udf cartridge, I get
[Tom@localhost Tom]$ ls -l /mnt
...
drwxr-xr-x 2 Tom root 4096 Nov 5 11:20 dvd
[Tom@localhost Tom]$ mount /mnt/dvd
[Tom@localhost Tom]$ ls -l /mnt
...
drwxr-xr-x 4 root root 140 Dec 6 19:13 dvd
[Tom@localhost Tom]$ umount /mnt/dvd
[Tom@localhost Tom]$ ls -l /mnt
...
drwxr-xr-x 2 Tom root 4096 Nov 5 11:20 dvd
If I then mount a FAT32 cartridge, I get
[Tom@localhost Tom]$ mount /mnt/dvd
[Tom@localhost Tom]$ ls -l /mnt
...
drwxrwxrwx 3 Tom Tom 16384 Dec 31 1969 dvd
...
[Tom@localhost Tom]$ mount
...
/dev/scd0 on /mnt/dvd type vfat (rw,nosuid,nodev,uid=500,umask=000)
Each time I mount a udf cartridge, I have to do su to chown it before I can write to it in user mode. Both the ownership and the permissions go back to the same root valuse, ignoring the fstab entry, until I do this. The behavior is the same for the Redhat kernel and the Win4Lin kernel.
I can get around this problem by adding myself to the root group, I think, but changing the permissions does not help. I found no clues in the mkudffs man page or in the linux-kernel archives.
Is there some trick for configuring to get around this problem? Is this a bug?
^ permalink raw reply
* "unexpected IO-APIC" in boot.msg
From: Karl Weigel @ 2002-12-11 7:54 UTC (permalink / raw)
To: linux-smp
Hi,
after changing to 2.4.20-kernel I analysed my logfiles and found a message,
that you like to be informed about this IO-APIC. I hope that the supplied
excerpt contains enough information to decide, whether this is interessting
to you. If you need more input, I will supply it, if I can.
I do not see, whether this APIC causes any problems for me.
Regards
Karl W. Weigel
--- excerpt from /var/log/boot.msg -------------------------------
<7>IO APIC #2......
<7>.... register #00: 02000000
<7>....... : physical APIC id: 02
<7>.... register #01: 00178002
<7>....... : max redirection entries: 0017
<7>....... : PRQ implemented: 1
<7>....... : IO APIC version: 0002
<4> WARNING: unexpected IO-APIC, please mail
<4> to linux-smp@vger.kernel.org
<7>.... IRQ redirection table:
<7> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
<7> 00 000 00 1 0 0 0 0 0 0 00
<7> 01 001 01 0 0 0 0 0 1 1 39
<7> 02 001 01 0 0 0 0 0 1 1 31
<7> 03 001 01 0 0 0 0 0 1 1 41
<7> 04 001 01 0 0 0 0 0 1 1 49
<7> 05 001 01 0 0 0 0 0 1 1 51
<7> 06 001 01 0 0 0 0 0 1 1 59
<7> 07 001 01 0 0 0 0 0 1 1 61
<7> 08 001 01 0 0 0 0 0 1 1 69
<7> 09 001 01 1 1 0 1 0 1 1 71
<7> 0a 001 01 0 0 0 0 0 1 1 79
<7> 0b 001 01 0 0 0 0 0 1 1 81
<7> 0c 001 01 0 0 0 0 0 1 1 89
<7> 0d 001 01 0 0 0 0 0 1 1 91
<7> 0e 001 01 0 0 0 0 0 1 1 99
<7> 0f 001 01 0 0 0 0 0 1 1 A1
<7> 10 000 00 1 0 0 0 0 0 0 00
<7> 11 000 00 1 0 0 0 0 0 0 00
<7> 12 000 00 1 0 0 0 0 0 0 00
<7> 13 000 00 1 0 0 0 0 0 0 00
<7> 14 000 00 1 0 0 0 0 0 0 00
<7> 15 000 00 1 0 0 0 0 0 0 00
<7> 16 000 00 1 0 0 0 0 0 0 00
<7> 17 000 00 1 0 0 0 0 0 0 00
^ permalink raw reply
* RE: boot sequence
From: Ray Olszewski @ 2002-12-11 7:56 UTC (permalink / raw)
To: Joseph D. Wagner, dave; +Cc: 'linux-newbie'
In-Reply-To: <001601c2a0e5$ae8c7230$972a3a41@joe>
Dave -- a try at answering your original question is at the end of this
message. In between is some reaction to Joseph's thoughts about what is and
is not appropriate for this list.
At 01:19 AM 12/11/02 -0600, Joseph D. Wagner wrote:
> > Joseph -- I think you may have gotten this list
> > mixed up with some other list that you subscribe
> > to. This list (linux-newbie) is a list for Linux
> > beginners to ask general questions on, NOT a list
> > for Linux kernel questions (at least, not exclusively).
>
>Yeah, but Dave CC'ed that list too.
How did you determine this? The copy of Dave's message that I received
here, the one that came through this list, does not show any Cc's. If he
posted to some kernel list separately, why drag linux-newbie into it at all
by cc'ing your reply to *that* message here?
> > While I don't know Mandrake so cannot myself answer
> > Dave's original question, it is hardly inappropriate
> > for a beginner's list.
>
>That's just my point. His question is about a specific distribution of
>Linux -- Mandrake. That's too specific for this list. I'm not saying it's
>inappropriate; I'm just saying he'd get a better response from a list
>specifically designed for Mandrake Linux, rather than posting to a general
>Linux list.
How long have you subscribed to linux-newbie? I regularly see here
questions that are specific to Red Hat, Slackware, and Debian ... probably
SuSE and Mandrake too, though I can't recall any specifically. Also
BasicLinux ... its creator even steers his users to this list by name. This
all seems very reasonable to me. When you are a beginner, in a sense *all*
your questions are specific to the distro you have installed ... at least
you don't know enough to know which are distro-specific, which are not ...
in fact, I have a bigger problem with the occasional poster who asks a
question but does not mention which distro he or she is using.
And the distro-specific lists are (in my, admittedly limited, experience)
sometimes populated by people with little patience for beginner-level
questions, folks who think "RTFM" is a helpful (or at least an appropriate)
reply to a beginner. This list has a fairly long tradition of treating
beginners a bit more graciously than I've seen elsewhere.
In fact, I suspect that Dave will learn that his initialization problems
are not specific to Mandrake. In that spirit, perhaps a general answer will
help him, so ...
... after the kernel is loaded, it starts the "init" process. That process
refers to the file /etc/inittab to determine (a) what runlevel to use and
(b) what init scripts to run. Typical inittab files have init first start
up in single-user mode and run a script listed on the "si" line (Debian
example: "si::sysinit:/etc/init.d/rcS"), then switch to the default
runlevel and run a script listed on the line for that runlevel (Debian
example: "l2:2:wait:/etc/init.d/rc 2" for runlevel 2).
Commonly, each of these scripts is a "wrapper" script that in turn runs a
collection of scripts identified by symlinks in a directory specific to
that runlevel; in Debian, for example, the single-user script runs all
scripts with symlinks having names that begin with "S" in /etc/rcS.d/, then
the runlevel-2 script runs all scripts with symlinks having names that
begin with "S" in /etc/rc2.d . The details (particularly the directory
names) will differ with Mandrake, but it, like every major distro (except
maybe Slackware and its derivatives), follows this general procedure
closely enough that you (Dave) can probably trace the init sequence by
starting at /etc/inittab and seeing what scripts it tells init to run when
the system starts up.
Hope this helps. If not, please do post more specific follow-up questions.
--
-------------------------------------------"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: Question on set_page_dirty()
From: Jan Hudec @ 2002-12-11 8:01 UTC (permalink / raw)
To: Martin Maletinsky; +Cc: linux-mm, kernelnewbies
In-Reply-To: <3DF5BB06.A6F6AFFD@scs.ch>
On Tue, Dec 10, 2002 at 10:59:34AM +0100, Martin Maletinsky wrote:
> Hello,
>
> Looking at the function set_page_dirty() (in linux 2.4.18-3 - see
> below) I noticed, that it not only sets the pages PG_dirty bit (as the
> SetPageDirty() macro does), but additionnally may link the page onto
> a queue (more precisely the dirty queue of it's 'mapping').
That's the most important bit of it all. All dirty pages must at some
point be cleaned. The list keeps track of which pages need to be
cleaned, so kernel can do it quickly either when it needs to free the
mapping (close the file, terminate process, exec) or when it's just time
to flush some pages (in kflushd).
> What is the meaning of this dirty queue, what is the effect of linking
> a page onto that queue, and when should the set_page_dirty() function
> be used rather than the
> SetPageDirty() macro?
If you use the SetPageDirty macro, then the page is marked dirty, but
kernel can't find it when it should clean it. Thus it eventualy won't
flush the data (it won't call writepage on it).
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Debugging Reiser4 with UML in 2.5
From: Oleg Drokin @ 2002-12-11 8:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: reiserfs-list
In-Reply-To: <20021210215237.43081.qmail@web14905.mail.yahoo.com>
Hello!
On Tue, Dec 10, 2002 at 01:52:37PM -0800, Jon Smirl wrote:
> I'm trying to give the new Reiser4 a whirl with UML in
> a 2.5 kernel. I can't seem to figure out how to make
> gdb work right in this setup. I've heard that UML is
> being used to develop Reiser4 so maybe you can give me
> some pointers.
Sure. Later on I assume that you use tt mode of UML (particularly
because skas mode is not very usable with reiser4 right now).
> I have the 2.4.59 kernel built with UML and Reiser4 in
> it. I can boot and come to a prompt. I can mount my
> reiser4 volume and make files on it, etc..
That's good.
> Now I start up ddd on the host and attach to the
> tracing thread for UML. I add a "br reiser4_read" and
> continue.
Hm. First of all you need to compile your UML with CONFIG_DEBUGSYM
and CONFIG_PT_PROXY config options.
> >From the UML prompt I cat a file. My UML console
> prints out "Trace/breakpoint trap" and continues.
>
> How do I get a gdb hooked to the right process so that
> it will catch the breakpoint?
Run gdb with these two options:
debug=parent gdb-pid=<pid>
where <pid> is pid of gdb process started by your ddd instance.
UML will stop after loading, now in ddd type
'att 1' (without quotes)
You will see something like this:
0xa013dc51 in __kill ()
Now put all of the breakpoints you are interested in and this kind of stuff
and execute 'c' command to continue UML boot.
After that it works like a debugging userspace threaded program.
See http://user-mode-linux.sourceforge.net/debugging.html fore more info.
Bye,
Oleg
^ permalink raw reply
* Re: portfw on iptables 2.4 kernel problem.
From: Joel Newkirk @ 2002-12-11 8:05 UTC (permalink / raw)
To: Reckhard, Tobias, netfilter
In-Reply-To: <96C102324EF9D411A49500306E06C8D1021AE36D@eketsv02.cubis.de>
On Wednesday 11 December 2002 02:32 am, Reckhard, Tobias wrote:
{heavily snipped by Joel}
> I expect you're trying to access the FTP server on 10.0.0.11 from the
> Internet by redirecting connections to the firewall's external IP
> address (203.100.100.1) to the FTP server.
> Take care of the FTP control connection:
> 2. Permit INPUT on the outside interface of the firewall to TCP port
> 21 with states NEW and ESTABLISHED
> 3. Permit OUTPUT on the outside interface of the firewall from TCP
> port 21 with state ESTABLISHED
> 4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
> 203.100.100.1 --dport 21" (see point 2 above) to the internal server
> at 10.0.0.11.
> 5. Permit FORWARDing of those same packets with states NEW and
> ESTABLISHED. 6. Permit FORWARDing of response packets ("-s 10.0.0.11
> --sport 21") with state ESTABLISHED.
This wouldn't work at all. INPUT shouldn't enter into it at all, unless
the DNAT fails, and OUTPUT only if a packet is required to leave the
firewall machine itself, IE if that is where the connection is attempted
from or to. Also, for the FTP conntrack helper to work you HAVE to
allow state RELATED. FTP will open a control connection to port 21,
then a request for data will (in passive) cause the server to attempt to
open a connection BACK to the client's port 20, IE. This is RELATED, in
a nutshell. The FTP helper is required because the control packets will
embed IP and port data inside the packet itself, rather than its header,
and without the helper netfilter will only handle the header.
j
^ permalink raw reply
* ANNOUNCE: UKW Tools 0.02 released
From: Jonathan Naylor @ 2002-12-11 8:05 UTC (permalink / raw)
To: linux-hams
Hi Folks
The G4KLX software foundry is happy to announce that UKW Tools 0.02 has
been released. So what is UKW Tools ?
UKW Tools is a kind of Goegraphic Information System (GIS) for radio
amateurs. Taking elevation data that is freely available on the
Internet, the program includes a suite of different funtions that allow
you to visualise radio paths and locations.
I suggest that you look on my web site http://www.qsl.net/g4klx under
Software and have a look at screen shots for more information, but
briefly, the current functions are:
3D Map: Produces a map centred on a location that shows the topography
around it. The colours may be changed, the viewing angle may be changed
as can the type of projection used.
Horizon View: Plots the elevations of the surrounding obstacles as
viewed from a site, an indication of their elevations and distance is
given.
Show Map: Displays a map centred on a location with different colours
used to denote heights. Moving the mouse over the map will result in
information about the location below the mouse (locator and elevation).
The colours may be changed.
Terrain: Given two locations the program will show the line of sight
path between them. In many ways this is the most interesting function.
The K (essentially the tropo conditions) value may be changed and when
the mouse is over the disgram some data about the location pointed to
will be shown.
There are two functions, Local Map and View which have not been
implemented yet.
UKW Tools 0.01 was released a little while ago but not announced because
it was a premature release to allow some operators to check their
sites.
UKW Tools is written in C++ and makes use of the platform independent
wxWindows toolkit and it is possible that it could be built on Windows
as well as Linux.
Jonathan G4KLX (HB9DRD until February 2003)
PS An article about the DSP functions used and the implementation of
LinWSJT is to be published in DUBUS 4/2002, and it can also be
downloaded from the Software page also. Warning, it is in Word 2000
format.
^ permalink raw reply
* IDE does not compile for PPC in 2.4.20+bk
From: Meelis Roos @ 2002-12-11 8:13 UTC (permalink / raw)
To: linux-kernel
make[1]: Entering directory `/home/mroos/compile/linux-2.4/arch/ppc/kernel'
gcc -D__KERNEL__ -I/home/mroos/compile/linux-2.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/home/mroos/compile/linux-2.4/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=setup -c -o setup.o setup.c
setup.c: In function `ppc_generic_ide_fix_driveid':
setup.c:674: structure has no member named `word89'
setup.c:674: structure has no member named `word89'
setup.c:674: structure has no member named `word89'
setup.c:674: structure has no member named `word89'
setup.c:675: structure has no member named `word90'
setup.c:675: structure has no member named `word90'
setup.c:675: structure has no member named `word90'
setup.c:675: structure has no member named `word90'
setup.c:677: structure has no member named `word92'
setup.c:677: structure has no member named `word92'
setup.c:677: structure has no member named `word92'
setup.c:677: structure has no member named `word92'
setup.c:681: structure has no member named `words95_99'
setup.c:681: structure has no member named `words95_99'
setup.c:681: structure has no member named `words95_99'
setup.c:681: structure has no member named `words95_99'
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH] compatibility syscall layer (lets try again)
From: george anzinger @ 2002-12-11 8:11 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Linus Torvalds, Jim Houston, Stephen Rothwell, LKML, anton,
David S. Miller, ak, davidm, schwidefsky, ralf, willy
In-Reply-To: <20021211071041.GA8988@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> On Tue, Dec 10, 2002 at 03:07:37PM -0800, george anzinger wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > On Fri, Dec 06, 2002 at 09:57:08AM -0800, Linus Torvalds wrote:
> > > >
> > > > I just pushed my version of the system call restart code to the BK trees.
> > > > It's losely based on Georges code, but subtly different. Also, I didn't
> > > > actually update any actual system calls to use it, I just did the
> > > > infrastructure.
> > > >
> > > > Non-x86 architectures need to be updated to work with this: they need to
> > > > update their thread structures, the additional do_signal() support in
> > > > their signal.c, and add the actual system call itself somewhere. For x86,
> > > > this was about 15 lines of changes.
> > > >
> > > > The basic premise is very simple: if you want to restart a system call,
> > > > you can do
> > > >
> > > > restart = ¤t_thread()->restart_block;
> > > > restart->fn = my_continuation_function;
> > > > restart->arg0 = my_arg0_for_continuation;
> > > > restart->arg1 = my_arg1_for_continuation;
> > > > ..
> > > > return -ERESTARTSYS_RESTARTBLOCK;
> > > >
> > > > which will cause the system call to either return -EINTR (if a signal
> > > > handler was actually invoced) or for "benign" signals (SIGSTOP etc) it
> > > > will end up restarting the system call at the continuation function (with
> > > > the "restart" block as the argument).
> > > >
> > > > We could extend this to allow restarting even over signal handlers, but
> > > > that would have some re-entrancy issues (ie what happens if a signal
> > > > handler itself wants to use a system call that may want restarting), so at
> > > > least for now restarting is only done when no handler is invoced (*).
> > > >
> > > > Linus
> > > >
> > > > (*) The nesting case is by no means impossible to handle gracefully
> > > > (adding a "restart even if handler is called" error number and returning
> > > > -EINTR if nesting, for example), but I don't know of any system calls that
> > > > would really want to try to restart anyway, so..
> > >
> > > Well, here's something to consider. This isn't entirely hypothetical;
> > > there are test cases in GDB's regression suite that cover nearly this.
> > >
> > > Suppose a process is sleeping for an hour. The user wants to see what
> > > another thread is doing, so he hits Control-C; the thread which happens
> > > to be reported as 'current' is the one that was in nanosleep(). It
> > > used to be that when he said continue, the nanosleep would return; now
> > > hopefully it'll continue. Great! But this damnable user isn't done
> > > yet. He wants to look at one of his data structures. He calls a
> > > debugging print_foo() function from GDB. He realizes he left a
> > > sleep-for-a-minute nanosleep call in it and C-c's again. Now we have
> > > two interrupted nanosleep calls and the application will never see a
> > > signal to interrupt either of them; he says "continue" twice and
> > > expects to get back to his hour-long sleep.
> > >
> > > Note that I'm not saying we _need_ to support this, mind :) It's a
> > > little pathological.
> >
> > I seem to recall working on a debugger in the distant past
> > and put a lock in it that did not allow it to run a debuggee
> > function while the debugee was in a system call. It seems
> > to me that is is begging for problems and is not that hard
> > for gdb/etc to prevent.
> >
> > Daniel, what to you think?
>
> I really don't see the point. I like being able to call functions
> while stopped in read() or poll(); you can hit C-c and go off to
> examine your application. That's as much "in a syscall" as this is.
Granted, and restarting them is a bit easier, to be sure.
But if the function does the same call it can hose the
program.
>
> Besides, implementing this is more of a pain than it's worth.
The problem we are left with is how to detect that a
nanosleep call that is interrupted and has set itself up to
continue and determine if it is, in fact, now handling that
continue call. Once we figure that out, we need to
understand what to do if it is not, i.e. what to do when the
call is continued. The "correct" thing to do would be to
stack all the relevant info on the user stack and pop it off
when needed much as what is done on a signal.
As it stands now, however, the detection of the need to do
this comes AFTER ptrace has handed control over to the
debugger and it has modified the users stack.
>
How about something like this:
1.) We use the same error returns as now and do not use a
new restart system call.
2.) Define a function "push_restart(struct restart_block
*restart)" which is called by the function when it detects
that it _may_ be restarted. This function would save the
restart block in a block of memory allocated from the slab
allocater and link it into the task, either the task_struct
or the thread_info. The function would add the current user
stack address and pc to the block.
3.) do_signal would toss the block and return the memory if
it determines that the call is not to be restarted.
4.) Define a "int pop_restart(struct restart_block
*restart)" function which the system call should call if it
is possible that it may be restarted. This function would
search the list of restart_blocks for the task doing:
a.) freeing any that have stack tags that are below the
current stack and
b.) returning the block with the current stack and pc
address, or null if not found.
This should be a true push down stack so that either a.) or
b.) will always be true unless there is no block for the
current call. I.e. the search can stop once the stack tag
is above the current user stack address.
We could put the first restart block in the task_struct or
thread_info area so we almost never allocate any memory.
So, is this overkill?
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* asoundc for routing all cards through one device
From: alfp @ 2002-12-11 8:10 UTC (permalink / raw)
To: alsa-devel
It took me a while to figure this out, so I thought i'd share it.
If you stick this into you .asoundrc, it creates a virtual device
called 'all', which will play to four cards at once.
ie aplay -Dall /usr/share/sounds/phone.wav
alf
######## All cards as one ####################
#### Device (pcm) definitions #############
pcm.m0 { type hw card 0 }
pcm.m1 { type hw card 1 }
pcm.m2 { type hw card 2 }
pcm.m3 { type hw card 3 }
#### Multi-device definition ##############
pcm.mlt {
type multi;
slaves [
{ pcm m0 channels 2 }
{ pcm m1 channels 2 }
{ pcm m2 channels 2 }
{ pcm m3 channels 2 }
]
bindings [
{ slave 0 channel 0 }
{ slave 0 channel 1 }
{ slave 1 channel 0 }
{ slave 1 channel 1 }
{ slave 2 channel 0 }
{ slave 2 channel 1 }
{ slave 3 channel 0 }
{ slave 3 channel 1 }
]
}
#### Auto-generated routing ###############
pcm.all {
type plug
slave { pcm mlt }
route_policy duplicate
}
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [PATCH] make net/ipv4/route.c compile without CONFIG_PROC_FS
From: David S. Miller @ 2002-12-11 8:47 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: Arnd Bergmann, Linux Kernel
In-Reply-To: <20021210212149.GN26067@conectiva.com.br>
On Tue, 2002-12-10 at 13:21, Arnaldo Carvalho de Melo wrote:
> uups, sorry, but this will not be needed after I convert the rest
> of net/ipv4/route.c to seq_file.
So I'll just wait for that :-)
^ permalink raw reply
* Tangent to: portfw on iptables 2.4 kernel problem.
From: Joel Newkirk @ 2002-12-11 8:15 UTC (permalink / raw)
To: netfilter
In-Reply-To: <96C102324EF9D411A49500306E06C8D1021AE36D@eketsv02.cubis.de>
In researching a rather long reply directly to Louie Miranda on this,
(with no answers, just many debugging suggestions) I enabled full
logging of all packets, with a DNAT from my firewall's external IP to a
LAN IP, then telnetted to that IP from the firewall machine. iptables
v1.2.5, RedHat 7.3 'stock' kernel.
The resulting logs surprised me.
The initial packet followed this route through the firewall chains:
mangle-OUTPUT
nat-OUTPUT
filter-OUTPUT
mangle-POSTROUTING
nat-POSTROUTING
out on lo and back
mangle-PREROUTING
mangle-INPUT
filter-INPUT
skipping nat-PREROUTING.
Subsequent packets in the connection (successful telnet to myself :^)
skipped ALL nat table rules.
Does netfilter normally skip NAT chains entirely when lo is involved? I
would have expected at least the initial packet to hit every chain.
(well, not FORWARD since the DNAT never took place...)
j
^ 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.