* Re: 2.4.23 SMP: kernel BUG at mmap.c
From: Chris Stromsoe @ 2004-01-26 22:51 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, Jens Axboe, shaggy
In-Reply-To: <Pine.LNX.4.58L.0401121836450.6737@logos.cnet>
On Mon, 12 Jan 2004, Marcelo Tosatti wrote:
> On Mon, 12 Jan 2004, Chris Stromsoe wrote:
> > Any hints about a cause or where to start looking for a problem?
>
> Hi Chris,
>
> Both BUGs seem to be related to some kind of race (the first one is a
> check for mm->map_count !=0 on exit_mmap and the second is a BH_Lock
> check at submit_bh()).
>
> First try to not use the md0 (use md1 or md2 directly then reconstruct
> the mirror later).
>
> If that fails, recompile your kernel without SMP.
>
> It might me a JFS problem.
I tried the suggestions and was able to force the error to occur. I took
the box out of service and ran memtest86 for a week and got a bunch of
errors. The problem appears to have been caused by faulty hardware.
I have the exact same configuration running in a box with duplicate
hardware and am not having any problems.
-Chris
^ permalink raw reply
* Beginners Luck??
From: Christian Unger @ 2004-01-26 22:52 UTC (permalink / raw)
To: netfilter
Hi
I'm running Linux 2.6.1 and iptables 1.2.8 ... there are a few issues that are
a mistery to me.
Iptables comes with the kernel? or does the kernel merely contain support, and
then an additional program sorta, jacks into that support?
Is there a reason why after running a firewall i might not be able to start
java applications (eg jEdit 4.1) - I get a splash screen but it just sits
there. this is using Java 1.4.2_01 (as shipped with Slackware 9.1)
--
with kind regards,
Christian Unger
- < > - < > - < > - < > - < > - < > - < > - < > -
Alt. Email: chakkerz_dev@optusnet.com.au
ICQ: 204184156
Mobile: 0402 268904
Web: http://naiv.sourceforge.net
^ permalink raw reply
* Re: Implementation of read( )
From: Glynn Clements @ 2004-01-26 22:51 UTC (permalink / raw)
To: vintya; +Cc: linux-c-programming
In-Reply-To: <20040126201655.DBEB51E447@xprdmailfe25.nwk.excite.com>
Vineet Joglekar wrote:
> I dont know if this question is relevant on this mailing list, but
> please do help me out if you can.
>
> For my project, I need to trace the read() function call till the VFS
> level. I have read that read() makes the kernel invoke sys_read() and
> I want to do the same thing with some additional functionalities.
> Where can i get the implementation of the read() function so that on
> the parallel lines I will be able to write my own my_read() function
> which in turn will call the sys_read() too?
read() is part of libc. However, it's just a trivial wrapper around
the corresponding system call; the "source code" in
sysdeps/unix/syscalls.list is just:
read - read i:ibn __libc_read __read read
The glibc build system generates the corresponding read.c file from
the above line using the sysdeps/unix/make-syscalls.sh script.
If you want to see the code, the simplest solution is to build glibc.
--
Glynn Clements <glynn.clements@virgin.net>
^ permalink raw reply
* Re: monochrome display fix.
From: Linus Torvalds @ 2004-01-26 22:48 UTC (permalink / raw)
To: James Simmons
Cc: Linus Torvalds, Linux Fbdev development list,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0401262212140.5445-100000@phoenix.infradead.org>
On Mon, 26 Jan 2004, James Simmons wrote:
>
> [CONSOLE] Don't let a monochrome display stomp all over the console color
> values.
Why is this ugly patch required? If something can't do color, why does it
care about "color" in the first place? We've never needed this patch
before, it looks like something broke somewhere _else_ that causes this
to be relevant.
Linus
^ permalink raw reply
* WARNING. You tried to send a potential virus or unauthorised code
From: alert-vdJTH0ZjJ4C+oSbvwQOFCLJmEfpfnwBNVpNB7YpNyf8 @ 2004-01-26 22:46 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
The MessageLabs SkyScan Anti-Virus service discovered a possible virus
or unauthorised code (such as a joke program or trojan) in an email sent
by you.
The email has now been quarantined and was not delivered.
Please read the whole of this email carefully. It explains what has
happened to your email, which suspected virus has been caught and what
to do if you need help addressing the problem.
To help identify the quarantined email:
The message sender was
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
The message recipients were
digilnux-6oL+oXf/A/s@public.gmane.org
The message title was hi
The message date was Mon, 26 Jan 2004 14:46:24 -0800
The virus or unauthorised code identified in the email is
/var/qmail/queue/split/0/attach/3384874_3X_AZ-S_PA2__data.pif
Found the W32/Mydoom-TkFRTFPJOQk@public.gmane.org virus !!!
Some viruses forge the sender address. For more information please
visit the link to the virus FAQ's at the bottom of this page.
The message was diverted into the virus holding pen on
mail server server-32.tower-29.messagelabs.com (pen id 3384874_1075157191)
and will be held for 30 days before being destroyed
Corporate Users:
If you sent the email from a corporate network, you should first
contact your local IT Helpdesk or System Administrator for advice.
They will be able to help you disinfect your workstation.
If you would like further information on how to subscribe to MessageLabs
SkyScan AV service, a proactive anti-virus service working around the
clock, around the globe, please complete our enquiry form.
Personal or Home users:
If you sent the email from a personal or home account, you will need
to disinfect your computer yourself. Please contact your anti-virus
software vendor for support.
You may like to read the virus FAQ's at:
http://www.messagelabs.com/page.asp?id=628
which will answer most virus related questions.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [patch 6/18] gcc-3.5: ipv6/ndisc.c fixes
From: Jan Oravec @ 2004-01-26 22:44 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev
In-Reply-To: <200401251107.i0PB7Go25072@mail.osdl.org>
Isn't syntax like:
> - skb->h.raw = (unsigned char*) msg = (struct nd_msg *) skb_put(skb, len);
> + skb->h.raw = (unsigned char*) (msg = (struct nd_msg *) skb_put(skb, len));
accepted in gcc-3.5 ?
The warning was about casting msg to unsigned char* and then assigning right
side into that expression with casts.
I wonder the old code did not produce warnings in gcc-3.3; it assigned to
unsigned char* variable a struct nd_msg* variable.
Jan
On Sun, Jan 25, 2004 at 03:07:16AM -0800, akpm@osdl.org wrote:
>
>
> net/ipv6/ndisc.c: In function `ndisc_send_na':
> net/ipv6/ndisc.c:478: warning: use of cast expressions as lvalues is deprecated
>
>
>
> ---
>
> net/ipv6/ndisc.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff -puN net/ipv6/ndisc.c~gcc-35-ip6-ndisc-fix net/ipv6/ndisc.c
> --- 25/net/ipv6/ndisc.c~gcc-35-ip6-ndisc-fix 2004-01-19 13:36:19.000000000 -0800
> +++ 25-akpm/net/ipv6/ndisc.c 2004-01-19 13:36:19.000000000 -0800
> @@ -475,7 +475,8 @@ static void ndisc_send_na(struct net_dev
> skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
> ip6_nd_hdr(sk, skb, dev, src_addr, daddr, IPPROTO_ICMPV6, len);
>
> - skb->h.raw = (unsigned char*) msg = (struct nd_msg *) skb_put(skb, len);
> + msg = (struct nd_msg *)skb_put(skb, len);
> + skb->h.raw = (unsigned char*)msg;
>
> msg->icmph.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT;
> msg->icmph.icmp6_code = 0;
> @@ -559,7 +560,8 @@ void ndisc_send_ns(struct net_device *de
> skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
> ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len);
>
> - skb->h.raw = (unsigned char*) msg = (struct nd_msg *)skb_put(skb, len);
> + msg = (struct nd_msg *)skb_put(skb, len);
> + skb->h.raw = (unsigned char*)msg;
> msg->icmph.icmp6_type = NDISC_NEIGHBOUR_SOLICITATION;
> msg->icmph.icmp6_code = 0;
> msg->icmph.icmp6_cksum = 0;
> @@ -630,7 +632,8 @@ void ndisc_send_rs(struct net_device *de
> skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
> ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len);
>
> - skb->h.raw = (unsigned char*) hdr = (struct icmp6hdr *) skb_put(skb, len);
> + hdr = (struct icmp6hdr *)skb_put(skb, len);
> + skb->h.raw = (unsigned char*)hdr;
> hdr->icmp6_type = NDISC_ROUTER_SOLICITATION;
> hdr->icmp6_code = 0;
> hdr->icmp6_cksum = 0;
> @@ -1374,7 +1377,8 @@ void ndisc_send_redirect(struct sk_buff
> ip6_nd_hdr(sk, buff, dev, &saddr_buf, &skb->nh.ipv6h->saddr,
> IPPROTO_ICMPV6, len);
>
> - buff->h.raw = (unsigned char*) icmph = (struct icmp6hdr *) skb_put(buff, len);
> + icmph = (struct icmp6hdr *)skb_put(buff, len);
> + buff->h.raw = (unsigned char*)icmph;
>
> memset(icmph, 0, sizeof(struct icmp6hdr));
> icmph->icmp6_type = NDISC_REDIRECT;
>
> _
>
^ permalink raw reply
* fbdev booting fix.
From: James Simmons @ 2004-01-26 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Linux Fbdev development list
Hi!
This is very critical bug fix. This bug was causing the problem with
people builing more than one driver with vesa and they where getting blank
screens. The reason was befor ethe api change each driver was loaded and
set as the default driver. Then you ended up with the last driver being
the default driver. Now this is the not the case so this patch makes the
first driver the default driver.
[FBCON] Fixed the order of which driver is used for the console. Before
the api change the last driver loaded became the default one. Now this is
not the case.
--- linus-2.6/drivers/video/console/fbcon.c 2004-01-26 13:38:23.000000000 -0800
+++ fbdev-2.6/drivers/video/console/fbcon.c 2004-01-26 17:14:00.000000000 -0800
@@ -545,7 +545,7 @@
return display_desc;
done = 1;
- info = registered_fb[num_registered_fb-1];
+ info = registered_fb[0];
if (!info) return NULL;
info->currcon = -1;
^ permalink raw reply
* [LARTC] Help with a simple config
From: jradke @ 2004-01-26 22:42 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]
Here's the scenario:
- 4 NIC's; 1 Upstream, 3 subscribers each with different rates.
NIC-1: NO CAP simply 100mbit
I want to cap the traffic on each of the subscriber NIC's to a specific rate
i.e.:
- NIC-2: 8mbit
- NIC-3: 5mbit
- NIC-4: 3mbit
Just to summarize, ALL I'm trying to do is limit the bandwidth on each NIC
(ingress & egress) whether it is 10/100/1000Base-T. Right now I am using a
Cisco using rate-limiting which is very simple. I'd like to perform this
task on Linux box for easier scalibility and as a backup.
Thanks for your assistance!
-JGR
[-- Attachment #2: Type: text/html, Size: 1190 bytes --]
^ permalink raw reply
* RE: FW: questions about production use
From: Williamson, Mark A @ 2004-01-26 22:41 UTC (permalink / raw)
To: Nick Craig-Wood; +Cc: xen-devel
> I'm a little concerned about keeping lots of data in a potentially
> non-standard disk format. I just hope its less troublesome than LVM
> which always seems to be losing its metadata and hence all the data on
> the disks!
The metadata for virtual disks is stored in an SQLite database on Dom0's
filesystem. It's probably good practice to keep it backed up, since you
won't be able to access the virtual disks without it, since the Dom0
tools wouldn't know where they are.
> > However, it is not safe to have two writers to one filesystem
>
> Sure. We'd either use it for migration in which case domX would be
> stopped, or for a hot backup in which case it wouldn't but it would be
> read only (no this isn't an ideal way to take a backup but its better
> than nothing!).
>
Well, if you find it works OK ;-)
> > There was an implementation of virtual disks in versions 1.0 and 1.1
> > but the rewrite adds support for the new Python-based toolchain and
> > some new features. AFAIK nobody has used the new VD tools "in
> > anger" yet but it's been working pretty solidly in testing.
>
> I'll see whether I can blow them up then ;-)
That would be very welcome. I'll try to fix anything you find problems
with. Feature suggestions are also welcome - you know best what things
would be useful, so please let us know! There's a TODO list in
XenoUtil.py (which contains the actual implementation) with some things
that I'm considering doing anyway. Any more ideas or comments are
welcome.
Note that you need sqlite and pysqlite installed for virtual disk
management to work. There's a tarball at
http://www.cl.cam.ac.uk/netos/xen/downloads/pysqlite-all-2.8.11-1.tgz of
all the files they need, or you can install them separately.
> > The virtual disk howto is now slightly out of date but I will be
> > updating it presently. If you get stuck, there's always interactive
> > help on the mailing list ;-) - I can feed back any
> discussions we have
> > to make the docs better.
>
> Great.
I've now updated the HOWTO, so that should end up on bkbits at some
stage soonish.
>> [me talking about re-exporting devices / files]
>
> This would be a useful feature for us and it would alleviate the
> potential pain of having data stored in non-standard disk formats.
> Howewever I can see the virtual disk space would be faster.
I would expect virtual disks to be faster, since it is fairly close to
being raw disk access, rather than having to indirect through a
filesystem. That said, disk performance should be as good or better
than you'd get from UML anyway.
Mark
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [LARTC] I can't get TCNG to compile!!!
From: jradke @ 2004-01-26 22:39 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]
Help! I can't get TCNG to compile!!! It did this on 2 different machines!
Here are the errors:
--------------------------------------------
Kernel: 2.4.22
[root@localhost tcng]# uname -a
Linux localhost.localdomain 2.4.22-1.2149.nptl #1 Wed Jan 7 13:08:26 EST
#if KFULLVERSIONNUM >= 0x20416 /* gratuitous interface change in 2.4.22 :-(
*/
ERROR:
ake -f Makefile.unclean tcsim
make[2]: Entering directory `/home/jradke/tcng/tcsim'
cc -E -g -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -I../shared -Iklib -Iklib/include
-Iulib/iproute2/include -I. -DVERSION=\"`cat ../VERSION`\"
-DTOPDIR=\"/home/jradke/tcng\" -DTCC_CMD=\"/home/jradke/tcng/bin/tcc\"
-DKFULLVERSION=\"2.4.22-1.2149.nptlcustom\" -DKFULLVERSIONNUM=`printf
"0x%02x%02x%02x" 2 4 22`-1.2149.nptlcustom -DIVERSION=\"010824\" -I. -M *.c
>.depend || \
{ rm -f .depend; exit 1; }
trace.c:41:5: too many decimal points in number
make[2]: *** [.depend] Error 1
make[2]: Leaving directory `/home/jradke/tcng/tcsim'
make[1]: *** [tcsim] Error 2
make[1]: Leaving directory `/home/jradke/tcng/tcsim'
make: *** [all] Error 1
--------------------------------------------
Kernel: 2.6.1
ERROR:
klib/include/linux/errno.h:4:31: asm-generic/errno.h: No such file or
directory
make[2]: *** [.depend] Error 1
make[2]: Leaving directory `/home/jradke/tcng/tcsim'
make[1]: *** [tcsim] Error 2
make[1]: Leaving directory `/home/jradke/tcng/tcsim'
make: *** [all] Error 1
[-- Attachment #2: Type: text/html, Size: 2753 bytes --]
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: George Anzinger @ 2004-01-26 22:35 UTC (permalink / raw)
To: Tom Rini; +Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <20040126214246.GD32525@stop.crashing.org>
Tom Rini wrote:
>>>>>+
>>>>>/*
>>>>>* Routines
>>>>>*/
>>>>>static void
>>>>>kgdb_debugger(struct pt_regs *regs)
>>>>>{
>>>>>- (*linux_debug_hook) (0, 0, 0, regs);
>>>>>+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>>>> return;
>>>>>}
>>>>>
>>>>>@@ -52,14 +109,14 @@
>>>>>int
>>>>>kgdb_iabr_match(struct pt_regs *regs)
>>>>>{
>>>>>- (*linux_debug_hook) (0, 0, 0, regs);
>>>>>+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>>>> return 1;
>>>>>}
>>>>>
>>>>>int
>>>>>kgdb_dabr_match(struct pt_regs *regs)
>>>>>{
>>>>>- (*linux_debug_hook) (0, 0, 0, regs);
>>>>>+ (*linux_debug_hook) (0, computeSignal(regs->trap), 0, regs);
>>>>> return 1;
>>>>>}
>>>>>
>>>>>
>>>>>Now, not being as well versed in all of the debugging infos that can be
>>>>>passed around, it sounds like this patch could be dropped in the future
>>>>>for a cleaner method using some of the dwarf2 bits being talked about.
>>>>>But I don't know, and clarification and pointers (if so) to how to do
>>>>>this would be appreciated.
>>>>
>>>>I am not sure what this buys you. I don't think dwarf2 will help here.
>>>
>>>
>>>OK.
>>>
>>>
>>>
>>>>There is a real danger of passing signal info back to gdb as it will want
>>>>to try to deliver the signal which is a non-compute in most kgdbs in the
>>>>field. I did put code in the mm-kgdb to do just this, but usually the
>>>>arrival of such a signal (other than SIGTRAP) is the end of the kernel.
>>>>All that is left is to read the tea leaves.
>>>
>>>
>>>The gdb I've been testing this with knows better than to try and send a
>>>singal back, so that's not a worry. The motivation behind doing this
>>>however is along the lines of "if it ain't broke, don't remove it". The
>>>original stub was getting all of this information correctly, so why stop
>>>doing it?
>>>
>>
>>OK, but I still don't like losing the return address. Tell me again, why
>>do you need three different functions all doing the same thing?
>
>
> You get:
> - kgdb_breakpoint => debugger_bpt : This is how the various PPC codes
> drop you into KGDB.
> - kgdb_iabr_match => debugger_iabr_match : Called from
> InstructionBreakpoint, exception.
> - kgdb_dabr_match => debugger_dabr_match : Called from do_page_fault,
> this is a Data Access Breakpoint Register match.
>
> So we need at least 2 for the KGDB side of things (prototypes) and 3
> just to make it clear.
But they all end up at the exact same place with the same set of parameters.
The only difference I can see is that some return 1 while the other is void. It
seems to me that you could send them all to one of the ones that returns 1.
Once that is done, then you could just send them all to where ever
linux_debug_hook points and have it do the signal resolution and return the 1.
That way that code could look at its return address and see something useful.
>
--
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
* Re: [Kernel-janitors] [PATCH] drivers/ide/ide-tape.c - handle
From: Randy.Dunlap @ 2004-01-26 22:34 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <20040122040839.GA2456@eugeneteo.net>
On Thu, 22 Jan 2004 12:08:39 +0800 Eugene Teo <eugene.teo@eugeneteo.net> wrote:
| I have not compile nor test this patch. stage has to be checked for
| null. No trailing spaces too :)
|
| 2902: static idetape_stage_t *__idetape_kmalloc_stage (..........)
| [...]
| 2909: if ((stage = (idetape_stage_t *) kmalloc (sizeof \
| (idetape_stage_t),GFP_KERNEL)) = NULL)
| 2910: return NULL;
|
| diff -Naur -X /home/amnesia/w/dontdiff 2.6.2-rc1-orig/drivers/ide/ide-tape.c 2.6.2-rc1-fix/drivers/ide/ide-tape.c
| --- 2.6.2-rc1-orig/drivers/ide/ide-tape.c 2004-01-22 02:19:18.000000000 +0800
| +++ 2.6.2-rc1-fix/drivers/ide/ide-tape.c 2004-01-22 12:01:56.000000000 +0800
| @@ -3619,6 +3619,8 @@
| printk(KERN_INFO "ide-tape: %s: reading back %d frames from the drive's internal buffer\n", tape->name, frames);
| for (i = 0; i < frames; i++) {
| stage = __idetape_kmalloc_stage(tape, 0, 0);
| + if (!stage)
| + return;
| if (!first)
| first = stage;
| aux = stage->aux;
|
so... what makes it OK for void function "idetape_onstream_read_back_buffer"
to just return at this point? It can't (or doesn't) return an error
AFAICT, but the calling function expected certain work to be done...
I guess that it could panic(), although I hate adding panics.
--
~Randy
kernel-janitors project: http://janitor.kernelnewbies.org/
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* [ANNOUCE] kpartx-0.0.2
From: christophe varoqui @ 2004-01-26 22:33 UTC (permalink / raw)
To: linux-hotplug
Hello,
here is the second release of kpartx : the shameless perversion of
util-linux's partx.
As before it :
1) compiles against klibc
2) read partitions table like partx
3) drives the device mapper to present the partitions bdevs
Find it at http://dsit.free.fr/kpartx-0.0.2.tar.bz2
This release adds a interesting functionality : it can now read
partitions tables from regular files, automagically assign a loop device
(like the mount cmd), and map devmaps from here.
Example : here, /tmp/test is a dump of an USB key
root@zezette../kpartx-0.0.2$ ./kpartx -a -v /tmp/test
last_lba(): I don't know how to handle files with mode 81a4
gpt: 0 slices
dos: 6 slices
reduced size of partition #2 to 32
Added loop0p1 : 0 15968 /dev/loop0 32
Added loop0p2 : 0 32 /dev/loop0 16000
Added loop0p5 : 0 6432 /dev/loop0 16032
Added loop0p6 : 0 9504 /dev/loop0 22496
root@zezette../kpartx-0.0.2$ ./kpartx -d -v /tmp/test
last_lba(): I don't know how to handle files with mode 81a4
gpt: 0 slices
dos: 6 slices
loop found : /dev/loop0
Deleted device map : loop0p1
Deleted device map : loop0p2
Deleted device map : loop0p5
Deleted device map : loop0p6
loop deleted : /dev/loop0
I heard there was some work to make the loop kernel driver partitionable ...
Is it still worth it ?
Is there interest in this tool, or ideas ? If there is, how to keep the
ball rolling ?
regards,
cvaroqui
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: 2.6.1: usblp.c: usblp0: nonzero read/write bulk status received
From: Jonathan Kamens @ 2004-01-26 22:31 UTC (permalink / raw)
To: Ulrich Schenck; +Cc: linux-kernel
In-Reply-To: <E1AlEOU-0000cj-00@castle>
The consensus of the messages I've seen on this topic seem to suggest
that you need to try using a shorter USB cable. Even valid cables of
the legal length seem to cause this problem for some printers where
shorters cables don't.
jik
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Nigel Cunningham @ 2004-01-26 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Pavel Machek, Hugang, Patrick Mochel, Linux Kernel Mailing List,
linuxppc-dev list
In-Reply-To: <1075154452.6191.91.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
Hi.
On Tue, 2004-01-27 at 11:00, Benjamin Herrenschmidt wrote:
> Also, at least on pmac laptops, the HD is usually so fast, that
> I suspect spending 10 seconds freeing things is less efficient than
> spending this 10 seconds writing 200Mb of data to disk :) Also, one
> wakup, it's quite painful to see everything be swapped in again. It
> may make sense to be less agressive on the memory freeing, though
> finding a good balance isn't easy.
Yes. That's why suspend2 doesn't free any memory at all by default, but
gives the user the option of setting a maximum image size.
Regards,
Nigel
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH]: altq HFSC port
From: Patrick McHardy @ 2004-01-26 22:27 UTC (permalink / raw)
To: David S. Miller; +Cc: hadi, netdev, linux-net
In-Reply-To: <401560A6.7030803@trash.net>
Patrick McHardy wrote:
>
> This mail from Alan states that BSD without advertising clause linked
> with GPL ends up as GPL anyways, so I'm not sure if there is a problem.
> http://www.ussg.iu.edu/hypermail/linux/kernel/0110.2/0924.html
> I'm going to look for some more information before bothering the
> authors with License stuff again.
>
I've tried to get some more information and clear up my misconceptions, I can
of course not just relicense the existing code. Since mixing GPL and BSD without
advertising clause is not a problem if the resulting code _as a whole_ is GPL, I
think I only have to mark the pre-existing code being subject to the original
license. The code as a whole is not dual-licensed, so MODULE_LICENSE stays GPL.
Does that sound reasonable ?
Best regards,
Patrick
^ permalink raw reply
* Re: [patch] udevd - cleanup and better timeout handling
From: Greg KH @ 2004-01-26 22:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040125200314.GA8376@vrfy.org>
On Mon, Jan 26, 2004 at 08:42:44PM +0100, Kay Sievers wrote:
> On Mon, Jan 26, 2004 at 11:28:19AM -0800, Greg KH wrote:
> > On Mon, Jan 26, 2004 at 08:11:10PM +0100, Kay Sievers wrote:
> > > On Mon, Jan 26, 2004 at 10:22:34AM -0800, Greg KH wrote:
> > > > On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
> > >
> > > So if we can get threads in klibc, I would prefer to switch to sockets.
> > > IPC isn't really a option for a todays program, but it works for us and
> > > sockets don't solve any big problem we have.
> >
> > Where would we need threads to do this? In udevsend? Can't we just
> > send the message to the socket and forget about it there?
>
> udevd need to be able to talk to multiple senders at the same time.
Hm, we can't use the same socket? I need to read up on how that all
works...
> Otherwise a simple connect from a client blocks the whole process.
>
> You may use select() for this and multiplex the connections, or fork
> a child and maintain the queue in shared memory. But that's all not
> really nice. I think threads are the nicest option, if you want sockets.
Ok, I'll trust you here :)
> > In udevd can't we just read the socket if any data is available?
>
> No, it blocks, until the client sends, or we need to poll.
Even if you accept on a socket that has O_NONBLOCK set on it?
> > No, I do not think klibc will ever support them, and state machines are
> > much nicer than multi threaded apps (for the most part.)
>
> What kind of state machine you are thinking of?
> How does it handle multiple client sockets. Do you mean a scheduler?
Hm, I don't know what kind of state machine I'm thinking of, usually you
can easily replace a program that has a lot of threads with a single one
using a state machine. But I've also written stuff that can't be done
that way (accepting serial data from one thread, etc.)
> > If sockets don't really help much, I'll go add support to klibc for ipc...
>
> I'm fine with it.
> We cant do it later if we want, when all the other problems are solved :)
That sounds fine with me :)
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: How do I get rid of these broadcasts in my logs
From: Michael Klinteberg @ 2004-01-26 22:22 UTC (permalink / raw)
To: Kit Massengill; +Cc: netfilter
In-Reply-To: <E8214FAA4482174EB648559A0AB63F75340F95@astro>
Kit Massengill wrote:
> Hi,
>
> I recently got a beautiful script from jlevie at experts-exchange that fixed
> my Linux router, but I need to now how to turn off the following broadcast
> loggings (eth1 is internal, obviously):
>
>
> <snip>
> Jan 23 09:35:21 ns1 kernel: Firewalled:IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:0d:88:52:15:15:08:00 SRC=192.168.1.111
> DST=192.168.1.255 LEN=249 TOS=0x00 PREC=0x00 TTL=128 ID=1732 PROTO=UDP
> SPT=138 DPT=138 LEN=229
> Jan 23 09:35:30 ns1 kernel: Firewalled:IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:50:8b:44:b0:3e:08:00 SRC=192.168.1.50
> DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=50311 PROTO=UDP
> SPT=137 DPT=137 LEN=58
> Jan 23 09:35:35 ns1 kernel: Firewalled:IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:a0:c9:8d:8d:39:08:00 SRC=192.168.1.33
> DST=255.255.255.255 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=50577 PROTO=UDP
> SPT=2301 DPT=2301 LEN=20
> Jan 23 09:35:36 ns1 kernel: Firewalled:IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:09:6b:1f:78:49:08:00 SRC=192.168.1.104
> DST=192.168.1.255 LEN=249 TOS=0x00 PREC=0x00 TTL=128 ID=38960 PROTO=UDP
> SPT=138 DPT=138 LEN=229
> Jan 23 09:35:53 ns1 kernel: Firewalled:IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:a0:c9:74:65:60:08:00 SRC=192.168.1.35
> DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=35506 PROTO=UDP
> SPT=137 DPT=137 LEN=58
> Jan 23 09:35:53 ns1 kernel: Firewalled:IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:a0:c9:74:65:60:08:00 SRC=192.168.1.35
> DST=192.168.1.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=37810 PROTO=UDP
> SPT=137 DPT=137 LEN=58
> <snip>
>
> Thanks,
> KitM
>
Take out some bits from the log and analyze it.
First one: IN=eth1, DST=192.168.0.255, PROTO=UDP, SPT=138, DPT=138
Next: IN=eth1, DST=192.168.0.255, PROTO=UDP, SPT=127, DPT=137
Next: IN=eth1, DST=255.255.255.255,PROTO=UDP,SPT=2301,DPT=2301
Next write the rules and drop them.
Remember that you have to insert them *before* the LOG rules.
iptables -A INPUT -i eth1 -d 192.168.0.255 -p UDP \
-m multiport --ports 137 -j DROP
iptables -A INPUT -i eth1 -d 192.168.0.255 -p UDP \
-m multiport --ports 138 -j DROP
#I'm not sure about this one, don't know what's it for
# iptables -A INPUT -i eth1 -d 255.255.255.255 -p UDP \
# -m multiport --ports 2301 -j DROP
Regards
Michael K
^ permalink raw reply
* Re: 2.6 sis900 (and tlan?) multicast bug
From: Jeff Garzik @ 2004-01-26 22:22 UTC (permalink / raw)
To: Joseph Fannin; +Cc: netdev
In-Reply-To: <20040126204215.GA25578@rivenstone.net>
Joseph Fannin wrote:
> "Craig A. Huegen" <huegen@pentics.com> wrote:
>
>>In the same vein as:
>>http://seclists.org/lists/linux-kernel/2003/Oct/5794.html
>
>
>>...there is a bug in the SiS900 driver in 2.6.1 which prevents multicast
>>MAC filtering from working properly. This breaks IPv6.
>
>
> I'm seeing this problem too. My sis900 interface can't get an
> IPv6 address unless promiscious or allmulti mode is set, since it
> doesn't get responses on ip6-allrouters.
>
> Please note that I am not subscribed to netdev, so a CC on any
> responses would be appreciated.
>
>
>>Patch attached (same one as from the 2.4 post from Oct 28) that made
>>IPv6 work for me again.
>
>
> From the original post, referring to the change this reverts:
>
>
>>>This will not work for bit_nr larger than 16 and hence the failure.
>>>Reverting to use set_bit causes multicast to be handled properly.
>
>
>>--- linux/drivers/net/sis900.c.old 2004-01-17 03:56:53.893211412 -0600
>>+++ linux/drivers/net/sis900.c 2004-01-17 03:57:02.785567615 -0600
>>@@ -2091,9 +2091,8 @@
>> rx_mode = RFAAB;
>> for (i = 0, mclist = net_dev->mc_list; mclist && i < net_dev->mc_count;
>> i++, mclist = mclist->next) {
>>- unsigned int bit_nr =
>>- sis900_mcast_bitnr(mclist->dmi_addr, revision);
>>- mc_filter[bit_nr >> 4] |= (1 << bit_nr);
>>+ set_bit(sis900_mcast_bitnr(mclist->dmi_addr, revision),
>>+ mc_filter);
>> }
>> }
>
>
> This fix didn't go into 2.4 either, so presumably something is wrong
> with it (perhaps we're moving away from set_bit)? I am over my head
> here really, but I don't want to just set allmulti mode and forget
> about this bug.
Correct, set_bit should only occur on unsigned long variables. So, the
code needs to manually set that bit.
Jeff
^ permalink raw reply
* Re: [ANNOUNCE] udev 015 release
From: Tomasz Torcz @ 2004-01-26 22:15 UTC (permalink / raw)
To: LKML
In-Reply-To: <20040126215036.GA6906@kroah.com>
On Mon, Jan 26, 2004 at 01:50:36PM -0800, Greg KH wrote:
> I've released the 015 version of udev. It can be found at:
Great, 15 minuts after I've installed 014 ;-)
014 and 015 errors for me when made with 'make USE_DBUS=true':
udev_dbus.c: In function `sysbus_connect':
udev_dbus.c:41: warning: implicit declaration of function `dbg'
gcc -ldbus-1 -o udev udev.o udev_config.o udev-add.o udev-remove.o \
udevdb.o logging.o namedev.o namedev_parse.o /mnt/ram/udev-015/libsysfs/sysfs_bus.o \
/mnt/ram/udev-015/libsysfs/sysfs_class.o /mnt/ram/udev-015/libsysfs/sysfs_device.o \
/mnt/ram/udev-015/libsysfs/sysfs_dir.o /mnt/ram/udev-015/libsysfs/sysfs_driver.o \
/mnt/ram/udev-015/libsysfs/sysfs_utils.o /mnt/ram/udev-015/libsysfs/dlist.o \
tdb/tdb.o tdb/spinlock.o udev_dbus.o -lc
udev_dbus.o(.text+0x49): In function `sysbus_connect':
: undefined reference to `dbg'
udev_dbus.o(.text+0x11f): In function `sysbus_send_create':
: undefined reference to `dbg'
udev_dbus.o(.text+0x1ce): In function `sysbus_send_remove':
: undefined reference to `dbg'
collect2: ld returned 1 exit status
make: *** [udev] Error 1
(manually wrapped line with gcc in above log).
Thats with dbus-0.20 installed.
--
Tomasz Torcz Elvis Presley nie żyje. Winni są developerzy Debiana.
zdzichu@irc.-nie.spam-.pl -- marcoos w komentarzach na infojama.pl
|> Playing: - Radio 103,4 Blue FM : Najlepiej Dobrana Muzyka prosto z Poznania
^ permalink raw reply
* Linux-kernel Vimgra
From: bamse @ 2004-01-26 22:13 UTC (permalink / raw)
To: Linux-kernel
In-Reply-To: <KJ96L6GBC3DJ3EJ0@vger.kernel.org>
Hi, Linux-kernel!
I am a frienCd of Simmey. He said thaft you need VIAGRzA. On thNis site it cosQts $1.91 per pac8k. http://www.rxeasymeds.com/discounts/index.php?pid=evaph5545
Best regards, Tadek
^ permalink raw reply
* monochrome display fix.
From: James Simmons @ 2004-01-26 22:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Fbdev development list, Linux Kernel Mailing List
[CONSOLE] Don't let a monochrome display stomp all over the console color
values.
--- linus-2.6/drivers/char/vt.c 2004-01-26 13:34:39.000000000 -0800
+++ fbdev-2.5/drivers/char/vt.c 2004-01-21 17:36:26.000000000 -0800
@@ -1062,7 +1062,8 @@
underline = 0;
reverse = 0;
blink = 0;
- color = def_color;
+ if (can_do_color)
+ color = def_color;
}
/* console_sem is held */
@@ -1135,7 +1136,8 @@
* with white underscore (Linux - use
* default foreground).
*/
- color = (def_color & 0x0f) | background;
+ if (can_do_color)
+ color = (def_color & 0x0f) | background;
underline = 1;
break;
case 39: /* ANSI X3.64-1979 (SCO-ish?)
@@ -1143,19 +1145,23 @@
* Reset colour to default? It did this
* before...
*/
- color = (def_color & 0x0f) | background;
+ if (can_do_color)
+ color = (def_color & 0x0f) | background;
underline = 0;
break;
case 49:
- color = (def_color & 0xf0) | foreground;
+ if (can_do_color)
+ color = (def_color & 0xf0) | foreground;
break;
default:
- if (par[i] >= 30 && par[i] <= 37)
- color = color_table[par[i]-30]
- | background;
- else if (par[i] >= 40 && par[i] <= 47)
- color = (color_table[par[i]-40]<<4)
- | foreground;
+ if (can_do_color) {
+ if (par[i] >= 30 && par[i] <= 37)
+ color = color_table[par[i]-30]
+ | background;
+ else if (par[i] >= 40 && par[i] <= 47)
+ color = (color_table[par[i]-40]<<4)
+ | foreground;
+ }
break;
}
update_attr(currcons);
@@ -1290,9 +1296,11 @@
}
break;
case 8: /* store colors as defaults */
- def_color = attr;
- if (hi_font_mask == 0x100)
- def_color >>= 1;
+ if (can_do_color) {
+ def_color = attr;
+ if (hi_font_mask == 0x100)
+ def_color >>= 1;
+ }
default_attr(currcons);
update_attr(currcons);
break;
^ permalink raw reply
* Re: [2.4 patch] fix via-ircc.c .text.exit error
From: Jean Tourrilhes @ 2004-01-26 22:11 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Marcelo Tosatti, irda-users, linux-kernel, jgarzik, linux-net
In-Reply-To: <20040126210126.GG513@fs.tum.de>
On Mon, Jan 26, 2004 at 10:01:26PM +0100, Adrian Bunk wrote:
> On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
> >
> > Thanks you Adrian. Yes, I must confess that I never test
> > non-modular build (because it doesn't work).
> >...
>
> Are you saying it might compile statically, but it won't work?
>
> In this case, what about disallowing building it statically in the
> Config.in?
I never looked in details at those issues. Some people claim
it works, but personally I always had touble with driver init (double
initialisation). I don't want to disable it if some embedded people
depend on it (stable kernel => stable feature list).
My "solution" was to totally rework the driver init (and stack
init) in 2.5.X and put ample warning on my web page "use static at
your own risk".
Jean
^ permalink raw reply
* Re: [Qemu-devel] problem bringing up QEMU test
From: Fabrice Bellard @ 2004-01-26 22:09 UTC (permalink / raw)
To: kyle, qemu-devel
In-Reply-To: <200401260839.20562.kyle@silverbeach.net>
Verify that you don't have firewall (ipchains or iptables) rules that
prohibit routing to tun0.
Fabrice.
Kyle Hayes wrote:
> I'm doing something wrong somewhere. I am using Gentoo on x86 as the host.
> I've loaded the precompiled QEMU binary 0.5.2.
>
> I have the TUN/TAP device set up on the host:
>
> bash-2.05b# ifconfig tap0
> tap0 Link encap:Ethernet HWaddr FE:FD:00:00:00:00
> inet addr:172.20.0.1 Bcast:172.20.255.255 Mask:255.255.0.0
> inet6 addr: fe80::fcfd:ff:fe00:0/64 Scope:Link
> UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:5416 (5.2 Kb)
>
> I set up a direct host route to the other end:
>
> bash-2.05b# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 172.20.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tap0
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0
> 127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
> 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
>
>
> I'm running QEMU as root (not particularly safe, but I want to see if I can
> get it to work before I break things with permissions). The test image boots
> and runs, but the network doesn't work:
>
> bash-2.05b# ./qemu.sh
> Connected to host network interface: tun0
> Load kernel at 0xac100000 (0x00100000)
> Linux version 2.4.21 (bellard@voyager.localdomain) (gcc version 3.2.2 20030222
> (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003
> BIOS-provided physical RAM map:
> BIOS-e801: 0000000000000000 - 000000000009f000 (usable)
> BIOS-e801: 0000000000100000 - 0000000002000000 (usable)
> 32MB LOWMEM available.
> On node 0 totalpages: 8192
> zone(0): 4096 pages.
> zone(1): 4096 pages.
> zone(2): 0 pages.
> Kernel command line: console=ttyS0 root=/dev/hda sb=0x220,5,1,5 ide2=noprobe
> ide3=noprobe ide4=noprobe ide5=noprobe
> ide_setup: ide2=noprobe
> ide_setup: ide3=noprobe
> ide_setup: ide4=noprobe
> ide_setup: ide5=noprobe
> Initializing CPU#0
> Detected 2592.439 MHz processor.
> Calibrating delay loop... 5164.23 BogoMIPS
> Memory: 28880k/32768k available (1210k kernel code, 3500k reserved, 266k data,
> 64k init, 0k highmem)
> Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
> Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> CPU: L1 I cache: 8K<6>CPU: L2 cache: 128K
> CPU: Intel Pentium Pro stepping 03
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> apm: BIOS not found.
> Starting kswapd
> Journalled Block Device driver loaded
> Detected PS/2 Mouse Port.
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with no serial options enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16450
> ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
> Last modified Nov 1, 2000 by Paul Gortmaker
> NE*000 ethercard probe at 0x300: 52 54 00 12 34 56
> eth0: NE2000 found at 0x300, using IRQ 9.
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
> ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
> hda: QEMU HARDDISK, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: attached ide-disk driver.
> hda: 20480 sectors (10 MB) w/256KiB Cache, CHS=20/16/63
> Partition check:
> hda:
> Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 4096)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 64k freed
>
> Linux version 2.4.21 (bellard@voyager.localdomain) (gcc version 3.2.2 20030222
> (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003
>
> QEMU Linux test distribution (based on Redhat 9)
>
> Type 'exit' to halt the system
>
> sh-2.05b# ping -c 3 172.20.0.1
> PING 172.20.0.1 (172.20.0.1) 56(84) bytes of data.
> From 172.20.0.2 icmp_seq=1 Destination Host Unreachable
> From 172.20.0.2 icmp_seq=2 Destination Host Unreachable
> From 172.20.0.2 icmp_seq=3 Destination Host Unreachable
>
> --- 172.20.0.1 ping statistics ---
> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2019ms
> , pipe 3
> sh-2.05b# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
> sh-2.05b#
>
>
> I cannot ping the other direction either (host to QEMU). Also ^C doesn't go
> through to QEMU. I first typed ping without the -c and it just kept going...
>
> Clearly I'm not doing something right here. Any clues?
>
> I'm trying to work my way up to booting KNOPPIX in QEMU. It boots fine, but
> it cannot find any X server that works and then dies. Until I get simpler
> things running, I'm not going to worry about that too much :-)
>
> Best,
> Kyle
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
>
>
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Tom Rini @ 2004-01-26 22:06 UTC (permalink / raw)
To: George Anzinger
Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <40158A88.7070007@mvista.com>
On Mon, Jan 26, 2004 at 01:45:44PM -0800, George Anzinger wrote:
> Tom Rini wrote:
> >
> >>There is a real danger of passing signal info back to gdb as it will want
> >>to try to deliver the signal which is a non-compute in most kgdbs in the
> >>field. I did put code in the mm-kgdb to do just this, but usually the
> >>arrival of such a signal (other than SIGTRAP) is the end of the kernel.
> >>All that is left is to read the tea leaves.
> >
> >
> >The gdb I've been testing this with knows better than to try and send a
> >singal back, so that's not a worry. The motivation behind doing this
> >however is along the lines of "if it ain't broke, don't remove it". The
> >original stub was getting all of this information correctly, so why stop
> >doing it?
> >
> You sure. If so what gdb? And how does it know? I suppose you could tell
> it with a script, but then what if one forgets?
GNU gdb 6.0 (MontaVista 6.0-8.0.4.0300532 2003-12-24)
Copyright 2003 Free Software Foundation, Inc.
[snip]
[New Thread 289]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 289]
0x00000000 in ?? ()
(gdb) c
Continuing.
Can't send signals to this remote system. SIGSEGV not sent.
Noting that 0x0 is correct as the code that triggered this was:
static void (*dummy)(struct pt_regs *regs);
int drop_kgdb(void) {
struct pt_regs regs;
memset(®s, 0, sizeof(regs));
dummy(®s);
return 0;
}
module_init(drop_kgdb);
--
Tom Rini
http://gate.crashing.org/~trini/
^ 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.