* 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
* fbdev documentation patch
From: James Simmons @ 2004-01-26 22:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Linux Fbdev development list
Hi!
The below patch updates the framebuffer docs to reflect the requirement
that all driver names must end in fb. Please apply.
--- linus-2.6/Documentation/fb/modedb.txt 2004-01-26 13:31:19.000000000 -0800
+++ fbdev-2.6/Documentation/fb/modedb.txt 2004-01-26 16:32:23.000000000 -0800
@@ -51,10 +51,10 @@
Drivers that support modedb boot options
Boot Name Cards Supported
- ami - Amiga chipset frame buffer
+ amifb - Amiga chipset frame buffer
aty128fb - ATI Rage128 / Pro frame buffer
atyfb - ATI Mach64 frame buffer
- tdfx - 3D Fx frame buffer
+ tdfxfb - 3D Fx frame buffer
tridentfb - Trident (Cyber)blade chipset frame buffer
BTW, only a few drivers use this at the moment. Others are to follow
^ permalink raw reply
* Re: [PATCH] Big powermac update
From: Benjamin Herrenschmidt @ 2004-01-26 22:01 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, Linux Kernel list
In-Reply-To: <20040126152921.GF15271@stop.crashing.org>
>
> But that's how it starts out... :) If it turns out that you need to add
> more regs in later, can you please move all of the POWER4/GPUL
> definitions into their own file? Thanks.
Will do if it's really necessary. At this point it is really not :)
Ben.
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Benjamin Herrenschmidt @ 2004-01-26 22:00 UTC (permalink / raw)
To: Pavel Machek
Cc: Hugang, Patrick Mochel, Nigel Cunningham, ncunningham,
Linux Kernel Mailing List, linuxppc-dev list
In-Reply-To: <20040126181004.GB315@elf.ucw.cz>
On Tue, 2004-01-27 at 05:10, Pavel Machek wrote:
> Hi!
>
> > Ah, also: The "Freeing memory" phase takes forever. That should
> > really be fixed.
>
> Well, it does the trick for me, but it takes 50% or so of suspend
> time. Some memory managment guru making "freeing memory" faster would
> certainly be welcome.
> Pavel
> PS: But I'd like to keep it simple...
Haven't looked at it yet. Several crash reports so far, mostly
lockups right after printing the number of pages to save. I wonder
if we have something broken in there. It dies for me once too at
this point.
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.
^ permalink raw reply
* lost arp requests
From: Patrick Ahler @ 2004-01-26 22:02 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
A gateway machine broadcasts an arp request for A.B.C.x. Out of these 2
routers, A.B.C.d and A.B.C.e, using the gateway how does the gateway
know that A.B.C.x is actually behind A.B.C.e?
Does it look in the router's routing tables? At the DNAT / PREROUTING
table (using a stub network)?
The reason I ask is I have 2 routers using the same gateway, both
forward packets fine. But if I forward a packet from A.B.C.x through
A.B.C.e it will not come back because the gateway the routers use does
not know where to look for A.B.C.x on the return route. It will
broadcast a ton of arp requests for A.B.C.x, but never find it.
[-- Attachment #2: Type: text/html, Size: 3512 bytes --]
^ permalink raw reply
* Re: FIX
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2004-01-26 22:01 UTC (permalink / raw)
To: davem, acme; +Cc: erik, netdev, yoshfuji
In-Reply-To: <20040126.123042.104046496.davem@redhat.com>
In article <20040126.123042.104046496.davem@redhat.com> (at Mon, 26 Jan 2004 12:30:42 -0800 (PST)), "David S. Miller" <davem@redhat.com> says:
>
> Ok, I've figured out the bug. Arnaldo only fixed one of the
> two incorrect calls to sk_add_node() which should both be
> __sk_add_node().
Thanks you!
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Benjamin Herrenschmidt @ 2004-01-26 21:58 UTC (permalink / raw)
To: Colin Leroy
Cc: Hugang, Patrick Mochel, Nigel Cunningham, ncunningham,
Linux Kernel Mailing List, linuxppc-dev list
In-Reply-To: <20040126192154.2af0425b@jack.colino.net>
On Tue, 2004-01-27 at 05:21, Colin Leroy wrote:
> On 26 Jan 2004 at 11h01, Benjamin Herrenschmidt wrote:
>
> Hi,
>
> > Hrm... It tends to do that when it's not happy with something,
> > but I did get it working... Ah yes, do
> >
> > echo -n "disk" instead :) It doesn't like the trailing \n
>
> Thanks, worked better. Got an oops with ohci-hcd or ehci-hcd, though.
> shutdown worked after rmmoding these.
> However resume did not - got:
pmdisk will save to the first (or the last, I'm not sure) installed
swap partition, not what your say on the command line. It will _resume_
from what you say on the command line.
ben.
^ permalink raw reply
* Re: [PATCH] 2.4/2.6 use xdsdt to print table header
From: Len Brown @ 2004-01-26 21:58 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-kernel, ACPI Developers
In-Reply-To: <1073953935.6497.173.camel@patsy.fc.hp.com>
Accepted.
Thanks Alex,
-Len
On Mon, 2004-01-12 at 19:32, Alex Williamson wrote:
> I'm resending this patch to get it into the main ACPI source. This
> fixes a problem where the DSDT pointer in the FADT is NULL because it
> uses the 64bit XDSDT instead. The current code is happy to map a NULL
> address and return success to the caller. This can crash the system or
> printout garbage headers to the console. It's a simple matter to check
> table revision and use the XDSDT in favor of the DSDT. This has been
> living happily in both the 2.4 and 2.6 ia64 tree for some time. Please
> accept. Thanks,
>
> Alex
^ permalink raw reply
* Re: [PATCH] 2.4/2.6 use xdsdt to print table header
From: Len Brown @ 2004-01-26 21:58 UTC (permalink / raw)
To: Alex Williamson; +Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, ACPI Developers
In-Reply-To: <1073953935.6497.173.camel-Wmjt7DDUnIVxnVILBQAtiA@public.gmane.org>
Accepted.
Thanks Alex,
-Len
On Mon, 2004-01-12 at 19:32, Alex Williamson wrote:
> I'm resending this patch to get it into the main ACPI source. This
> fixes a problem where the DSDT pointer in the FADT is NULL because it
> uses the 64bit XDSDT instead. The current code is happy to map a NULL
> address and return success to the caller. This can crash the system or
> printout garbage headers to the console. It's a simple matter to check
> table revision and use the XDSDT in favor of the DSDT. This has been
> living happily in both the 2.4 and 2.6 ia64 tree for some time. Please
> accept. Thanks,
>
> Alex
-------------------------------------------------------
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
* Linux-mm ViWgra
From: zens @ 2004-01-26 21:54 UTC (permalink / raw)
To: Linux-mm
In-Reply-To: <32IJE3F9CCDGLB95@kvack.org>
Hi, Linux-mm!
I am a frien3d of Simmon. He said thapt you need VIAGRgA. On thCis site it cosBts $1.94 per pac9k. http://www.rxeasymeds.com/discounts/index.php?pid=evaph5545
Best regards, Bartel
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply
* [ANNOUNCE] udev 015 release
From: Greg KH @ 2004-01-26 21:50 UTC (permalink / raw)
To: linux-hotplug-devel, linux-kernel
I've released the 015 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm
udev allows users to have a dynamic /dev and provides the ability to
have persistent device names. It uses sysfs and /sbin/hotplug and runs
entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG
enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
Major changes from the 014 version:
- we finally look up the chain of sysfs device entries trying to
match all devices in the chain for each rule.
What this means to users: Consider the following sysfs device:
$ tree /sys/class/input/mouse1/
/sys/class/input/mouse1/
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
`-- driver -> ../../../bus/usb/drivers/hid
Now this is a USB trackball. udev will follow that "device" symlink and
get to the following directory:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- detach_state
|-- iInterface
`-- power
`-- state
This is the directory of the USB interface that is bound to a mouse
driver. But in itself, that directory is pretty boring, no vendor id,
no product id, no manufacturer string... What a user really wants is
the directory above this:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
|-- 2-1:1.0
| |-- bAlternateSetting
| ...
|-- bConfigurationValue
|-- bDeviceClass
|-- bDeviceProtocol
|-- bDeviceSubClass
|-- bMaxPower
|-- bNumConfigurations
|-- bNumInterfaces
|-- bcdDevice
|-- bmAttributes
|-- detach_state
|-- idProduct
|-- idVendor
|-- manufacturer
|-- power
| `-- state
|-- product
`-- speed
Now this directory contains good stuff:
$ cat /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/product
Microsoft Trackball Optical®
So, in short, you can now write a udev rule for this device as:
SYSFS_product="Microsoft Trackball*", NAME="my_trackball", SYMLINK="input/mouse1"
and it will actually work :)
This is really helpful for all USB devices, and SCSI devices on USB or
Firewire buses. If anyone has any questions about this, please let me
know, or bring it up on the linux-hotplug-devel mailing list.
Another big thing in this release is 'udevinfo'. It's a way to get all
information out of the udev database about what devices are present,
what they are called, and other good stuff. It also will walk the sysfs
chain of any device and print out all information on the device which
helps out a lot in creating rules for udev.
Thanks to Kay Sievers who wrote udevinfo. Great job.
Also in this release is the start of a udev daemon. It's really in 3
pieces:
udevsend - sends the hotplug message to the udev daemon
udevd - the udev daemon, gets the hotplug messages, sorts them
in proper order, and passes them off to the udev program
to act apon them.
udev - still the same.
This lets us keep udevsend and udevd small, and hopefully bug free.
These programs still need a lot of work and polish before we feel they
are stable enough to use for everyone (they are not built right now in
the .rpm). Help is appreciated here.
Thanks a lot to Kay Sievers and Xiaofeng Ling for the work on udevsend
and udevd. Again, I really appreciate it.
Thanks also to everyone who has send me patches for this release, a full
list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
thanks,
greg k-h
Summary of changes from v014 to v015
============================================
<mbuesch:freenet.de>:
o LFS init script update
Greg Kroah-Hartman:
o update klibc to version 0.98
o clean up udevinfo on 'make clean'
o add udevinfo man page to spec file
o remove command line documentation from udev man page
o create initial version of udevinfo man page
o added URL to spec file
o add udevinfo to udev.spec file
o add udevinfo to install target of Makefile
o rip out command line code from udev, now that we have udevinfo
o udevinfo doesn't need to declare main_envp
o move get_pair to udev_config.c because udevinfo doesn't need all of namedev.o
o more makefile cleanups
o move udevinfo into the main build and clean up the main Makefile a bit
o clean up compiler warnings if building using klibc
o make udevd only have one instance running at a time
o new testd.block script for debugging
o udevsnd : clean up message creation logic a bit
o make bk ignore udevd and udevsend binaries
o whitespace cleanups
o remove TODO item about BUS value, as it is now done
o add support for figuring out which device on the sysfs "chain" the rule applies to
Kay Sievers:
o udevinfo - now a real program :)
o udevd - cleanup and better timeout handling
o udev - next round of udev event order daemon
o fix udevd exec
o udev - udevinfo with device chain walk
o spilt udev into pieces
^ permalink raw reply
* [ANNOUNCE] udev 015 release
From: Greg KH @ 2004-01-26 21:50 UTC (permalink / raw)
To: linux-hotplug-devel, linux-kernel
I've released the 015 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm
udev allows users to have a dynamic /dev and provides the ability to
have persistent device names. It uses sysfs and /sbin/hotplug and runs
entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG
enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
Major changes from the 014 version:
- we finally look up the chain of sysfs device entries trying to
match all devices in the chain for each rule.
What this means to users: Consider the following sysfs device:
$ tree /sys/class/input/mouse1/
/sys/class/input/mouse1/
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
`-- driver -> ../../../bus/usb/drivers/hid
Now this is a USB trackball. udev will follow that "device" symlink and
get to the following directory:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- detach_state
|-- iInterface
`-- power
`-- state
This is the directory of the USB interface that is bound to a mouse
driver. But in itself, that directory is pretty boring, no vendor id,
no product id, no manufacturer string... What a user really wants is
the directory above this:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
|-- 2-1:1.0
| |-- bAlternateSetting
| ...
|-- bConfigurationValue
|-- bDeviceClass
|-- bDeviceProtocol
|-- bDeviceSubClass
|-- bMaxPower
|-- bNumConfigurations
|-- bNumInterfaces
|-- bcdDevice
|-- bmAttributes
|-- detach_state
|-- idProduct
|-- idVendor
|-- manufacturer
|-- power
| `-- state
|-- product
`-- speed
Now this directory contains good stuff:
$ cat /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/product
Microsoft Trackball Optical®
So, in short, you can now write a udev rule for this device as:
SYSFS_product="Microsoft Trackball*", NAME="my_trackball", SYMLINK="input/mouse1"
and it will actually work :)
This is really helpful for all USB devices, and SCSI devices on USB or
Firewire buses. If anyone has any questions about this, please let me
know, or bring it up on the linux-hotplug-devel mailing list.
Another big thing in this release is 'udevinfo'. It's a way to get all
information out of the udev database about what devices are present,
what they are called, and other good stuff. It also will walk the sysfs
chain of any device and print out all information on the device which
helps out a lot in creating rules for udev.
Thanks to Kay Sievers who wrote udevinfo. Great job.
Also in this release is the start of a udev daemon. It's really in 3
pieces:
udevsend - sends the hotplug message to the udev daemon
udevd - the udev daemon, gets the hotplug messages, sorts them
in proper order, and passes them off to the udev program
to act apon them.
udev - still the same.
This lets us keep udevsend and udevd small, and hopefully bug free.
These programs still need a lot of work and polish before we feel they
are stable enough to use for everyone (they are not built right now in
the .rpm). Help is appreciated here.
Thanks a lot to Kay Sievers and Xiaofeng Ling for the work on udevsend
and udevd. Again, I really appreciate it.
Thanks also to everyone who has send me patches for this release, a full
list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
thanks,
greg k-h
Summary of changes from v014 to v015
======================
<mbuesch:freenet.de>:
o LFS init script update
Greg Kroah-Hartman:
o update klibc to version 0.98
o clean up udevinfo on 'make clean'
o add udevinfo man page to spec file
o remove command line documentation from udev man page
o create initial version of udevinfo man page
o added URL to spec file
o add udevinfo to udev.spec file
o add udevinfo to install target of Makefile
o rip out command line code from udev, now that we have udevinfo
o udevinfo doesn't need to declare main_envp
o move get_pair to udev_config.c because udevinfo doesn't need all of namedev.o
o more makefile cleanups
o move udevinfo into the main build and clean up the main Makefile a bit
o clean up compiler warnings if building using klibc
o make udevd only have one instance running at a time
o new testd.block script for debugging
o udevsnd : clean up message creation logic a bit
o make bk ignore udevd and udevsend binaries
o whitespace cleanups
o remove TODO item about BUS value, as it is now done
o add support for figuring out which device on the sysfs "chain" the rule applies to
Kay Sievers:
o udevinfo - now a real program :)
o udevd - cleanup and better timeout handling
o udev - next round of udev event order daemon
o fix udevd exec
o udev - udevinfo with device chain walk
o spilt udev into pieces
-------------------------------------------------------
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
* [PATCH/RFC] cdev_unmap()
From: Jonathan Corbet @ 2004-01-26 21:48 UTC (permalink / raw)
To: linux-kernel; +Cc: viro
Drivers which use the cdev interface, it seems, must call cdev_unmap()
prior to removing their devices with cdev_del(). This is important -
otherwise the char dev subsystem maintains a non-reference-counted pointer
to the cdev structure, and references to the wrong device number after the
relevant module has been unloaded can create all sorts of internal
trouble.
The 2.6.2-rc2 st and sg drivers fail to call cdev_unmap(), for what it's
worth.
One can certainly document the cdev interface to note that, while a single
call (cdev_add()) is sufficient to add a cdev to the system, two calls are
required to remove it. And you must remember the device number and count
you used for cdev_add() too. All this can be made to work. It would be
better to bump the cdev's reference count for as long as a pointer lives in
cdev_map, though.
But why? It's an extra thing to remember, has catastrophic consequences if
somebody screws up (but driver programmers never do that), exposes some of
the cdev code's internal recordkeeping, and seems unnecessary. Can
somebody tell me if there's anything wrong with the following patch, which
eliminates the need to call cdev_unmap() and unexports it?
jon
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/drivers/char/tty_io.c 2.6.2-rc2/drivers/char/tty_io.c
--- 2.6.2-rc2-vanilla/drivers/char/tty_io.c 2004-01-27 02:14:22.000000000 -0700
+++ 2.6.2-rc2/drivers/char/tty_io.c 2004-01-27 04:44:30.000000000 -0700
@@ -2259,7 +2259,6 @@ int tty_unregister_driver(struct tty_dri
if (driver->refcount)
return -EBUSY;
- cdev_unmap(MKDEV(driver->major, driver->minor_start), driver->num);
unregister_chrdev_region(MKDEV(driver->major, driver->minor_start),
driver->num);
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/drivers/ieee1394/amdtp.c 2.6.2-rc2/drivers/ieee1394/amdtp.c
--- 2.6.2-rc2-vanilla/drivers/ieee1394/amdtp.c 2004-01-27 02:14:23.000000000 -0700
+++ 2.6.2-rc2/drivers/ieee1394/amdtp.c 2004-01-27 04:44:30.000000000 -0700
@@ -1308,7 +1308,6 @@ static void __exit amdtp_exit_module (vo
hpsb_unregister_highlevel(&amdtp_highlevel);
devfs_remove("amdtp");
- cdev_unmap(IEEE1394_AMDTP_DEV, 16);
cdev_del(&amdtp_cdev);
HPSB_INFO("Unloaded AMDTP driver");
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/drivers/ieee1394/dv1394.c 2.6.2-rc2/drivers/ieee1394/dv1394.c
--- 2.6.2-rc2-vanilla/drivers/ieee1394/dv1394.c 2004-01-27 02:14:23.000000000 -0700
+++ 2.6.2-rc2/drivers/ieee1394/dv1394.c 2004-01-27 04:44:30.000000000 -0700
@@ -2609,7 +2609,6 @@ static void __exit dv1394_exit_module(vo
hpsb_unregister_protocol(&dv1394_driver);
hpsb_unregister_highlevel(&dv1394_highlevel);
- cdev_unmap(IEEE1394_DV1394_DEV, 16);
cdev_del(&dv1394_cdev);
devfs_remove("ieee1394/dv");
}
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/drivers/ieee1394/raw1394.c 2.6.2-rc2/drivers/ieee1394/raw1394.c
--- 2.6.2-rc2-vanilla/drivers/ieee1394/raw1394.c 2004-01-27 02:14:24.000000000 -0700
+++ 2.6.2-rc2/drivers/ieee1394/raw1394.c 2004-01-27 04:44:30.000000000 -0700
@@ -2682,7 +2682,6 @@ static int __init init_raw1394(void)
static void __exit cleanup_raw1394(void)
{
hpsb_unregister_protocol(&raw1394_driver);
- cdev_unmap(IEEE1394_RAW1394_DEV, 1);
cdev_del(&raw1394_cdev);
devfs_remove(RAW1394_DEVICE_NAME);
hpsb_unregister_highlevel(&raw1394_highlevel);
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/drivers/ieee1394/video1394.c 2.6.2-rc2/drivers/ieee1394/video1394.c
--- 2.6.2-rc2-vanilla/drivers/ieee1394/video1394.c 2004-01-27 02:14:24.000000000 -0700
+++ 2.6.2-rc2/drivers/ieee1394/video1394.c 2004-01-27 04:44:30.000000000 -0700
@@ -1447,7 +1447,6 @@ static void __exit video1394_exit_module
hpsb_unregister_highlevel(&video1394_highlevel);
devfs_remove(VIDEO1394_DRIVER_NAME);
- cdev_unmap(IEEE1394_VIDEO1394_DEV, 16);
cdev_del(&video1394_cdev);
PRINT_G(KERN_INFO, "Removed " VIDEO1394_DRIVER_NAME " module");
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/fs/char_dev.c 2.6.2-rc2/fs/char_dev.c
--- 2.6.2-rc2-vanilla/fs/char_dev.c 2004-01-27 02:14:04.000000000 -0700
+++ 2.6.2-rc2/fs/char_dev.c 2004-01-27 05:14:36.000000000 -0700
@@ -240,7 +240,6 @@ void unregister_chrdev_region(dev_t from
int unregister_chrdev(unsigned int major, const char *name)
{
struct char_device_struct *cd;
- cdev_unmap(MKDEV(major, 0), 256);
cd = __unregister_chrdev_region(major, 0, 256);
if (cd && cd->cdev)
cdev_del(cd->cdev);
@@ -347,6 +346,8 @@ int cdev_add(struct cdev *p, dev_t dev,
err = kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p);
if (err)
kobject_del(&p->kobj);
+ p->dev = dev;
+ p->count = count;
return err;
}
@@ -357,6 +358,7 @@ void cdev_unmap(dev_t dev, unsigned coun
void cdev_del(struct cdev *p)
{
+ cdev_unmap(p->dev, p->count);
kobject_del(&p->kobj);
kobject_put(&p->kobj);
}
@@ -458,6 +460,5 @@ EXPORT_SYMBOL(cdev_get);
EXPORT_SYMBOL(cdev_put);
EXPORT_SYMBOL(cdev_del);
EXPORT_SYMBOL(cdev_add);
-EXPORT_SYMBOL(cdev_unmap);
EXPORT_SYMBOL(register_chrdev);
EXPORT_SYMBOL(unregister_chrdev);
diff -urNp -X dontdiff 2.6.2-rc2-vanilla/include/linux/cdev.h 2.6.2-rc2/include/linux/cdev.h
--- 2.6.2-rc2-vanilla/include/linux/cdev.h 2003-09-08 13:50:09.000000000 -0600
+++ 2.6.2-rc2/include/linux/cdev.h 2004-01-27 04:38:57.000000000 -0700
@@ -7,6 +7,8 @@ struct cdev {
struct module *owner;
struct file_operations *ops;
struct list_head list;
+ dev_t dev;
+ unsigned int count;
};
void cdev_init(struct cdev *, struct file_operations *);
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: George Anzinger @ 2004-01-26 21:45 UTC (permalink / raw)
To: Tom Rini; +Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <20040126204631.GB32525@stop.crashing.org>
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?
--
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
* ia32 instruction sets
From: Frederic Beuserie @ 2004-01-26 21:46 UTC (permalink / raw)
To: linux-assembly
hi,
i've downloaded the references from intel for ia32/P4 cpus and it appears it's not really easy to use it as a "hand" reference (pdf, ...)
did you know a location where there's a comprensive and easily browseable reference of ia32 instructions, coupled with the syntax i gas use.
thanks.
frederic b.
^ permalink raw reply
* [Bluez-devel] Device specific pins
From: Dave Henriksen @ 2004-01-26 21:44 UTC (permalink / raw)
To: BlueZ Mailing List
Hi,
Just wondering if there is any way to have pins that vary depending upon
what device you are connecting to. Currently, I just use
/etb/bluetooth/givepin to supply a pin, but this pin must be the same
for every device that my Linux laptop connects to.
Thanks,
Dave Henriksen
-------------------------------------------------------
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
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: Adaptec 2100S
From: Ray Olszewski @ 2004-01-26 21:43 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <Pine.LNX.4.56.0401261723230.18923@pluton.chilepac.com>
At 05:29 PM 1/26/2004 -0300, Rodrigo Gesswein wrote:
>Hello!
>
> I have a new server with an Adaptec 2100S hardware raid controller
>and _only_ scsi hard disks. I'm trying to install debian linux 3.0r2 but the
>hard disk are not recognized by the default kernel.
> Does anyone have a clue about this situation ?? any information will
>be very usefull.
Info on this seems to be fairly hard to track down. With a bit of Googling,
I turned up this much:
Apparently the 2100s requires a dpt_i2o.o module. This is (or was; I can't
find an actual link) available from Adaptec, and it *may* be the same
module that is now part of recent 2.4.x kernels (associated with "Adaptec
I2O RAID support").
In any case, this link the closest I can to working instructions ...
http://www.togaware.com/linux/survivor/Load_RAID.html
... and it does not describe a complete process -- though it does discuss
compiling the module for kernel 2.2.19 and concerting the Debian bootdisks
to use that kernel.
I suspect you will need eventually to compile a kernel with initrd support
so it can load the needed modules before trying to mount the root
filesystem on the RAID array. Or you will need to boot/init from a
different location -- were I facing this problem, I'd add a small (10-20 GB
or so, small by today's standards) IDE drive and use it as boot media and
the root filesystem ... mounting the RAID array at a point appropriate to
whatever use calls for a RAID array (/home ? some database directory?).
For more information, try Googling "linux Adaptec 2100S debian".
Especially if you read German (I don't), you'll find a lot.
-
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: [2.4 patch] fix via-ircc.c .text.exit error
From: Jean Tourrilhes @ 2004-01-26 21:42 UTC (permalink / raw)
To: David S. Miller
Cc: bunk, marcelo.tosatti, irda-users, linux-kernel, jgarzik,
linux-net
In-Reply-To: <20040126.130242.74547942.davem@redhat.com>
On Mon, Jan 26, 2004 at 01:02:42PM -0800, David S. Miller wrote:
> From: Adrian Bunk <bunk@fs.tum.de>
> Date: Mon, 26 Jan 2004 22:01:26 +0100
>
> 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?
>
> It won't link because many IRDA drivers erroneously don't
> mark their module_{init,exit}() routines static, thus
> symbols conflict.
>
> I'm fixing that now.
I was talking with Adrian about 2.4.X where things are quite
different with respect to driver initialisation.
Jean
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Tom Rini @ 2004-01-26 21:42 UTC (permalink / raw)
To: George Anzinger
Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <40158647.70701@mvista.com>
On Mon, Jan 26, 2004 at 01:27:35PM -0800, George Anzinger wrote:
> Tom Rini wrote:
> >On Fri, Jan 23, 2004 at 03:38:39PM -0800, George Anzinger wrote:
> >
> >>Tom Rini wrote:
> >>
> >>>On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
> >>>[snip]
> >>>
> >>>
> >>>>First up:
> >>>>We need to call flush_instruction_cache() on a 'c' or 's' command.
> >>>>arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------
> >>>>1 files changed, 6 insertions(+), 13 deletions(-)
> >>>
> >>>
> >>>On tpo of this patch, there's the following:
> >>>Put back some code to figure out what signal we're dealing with.
> >>>
> >>>arch/ppc/kernel/ppc-stub.c | 63
> >>>++++++++++++++++++++++++++++++++++++++++++---
> >>>1 files changed, 60 insertions(+), 3 deletions(-)
> >>>--- 1.15/arch/ppc/kernel/ppc-stub.c Thu Jan 22 10:53:06 2004
> >>>+++ edited/arch/ppc/kernel/ppc-stub.c Fri Jan 23 15:43:10 2004
> >>>@@ -3,6 +3,7 @@
> >>>*
> >>>* PowerPC-specific bits to work with the common KGDB stub.
> >>>*
> >>>+ * 1998 (c) Michael AK Tesch (tesch@cs.wisc.edu)
> >>>* 2003 (c) TimeSys Corporation
> >>>* 2004 (c) MontaVista Software, Inc.
> >>>* This file is licensed under the terms of the GNU General Public License
> >>>@@ -19,13 +20,69 @@
> >>>#include <asm/processor.h>
> >>>#include <asm/machdep.h>
> >>>
> >>>+/* Convert the hardware trap type code to a unix signal number. */
> >>>+/*
> >>>+ * This table contains the mapping between PowerPC hardware trap types,
> >>>and
> >>>+ * signals, which are primarily what GDB understands.
> >>>+ */
> >>>+static struct hard_trap_info
> >>>+{
> >>>+ unsigned int tt; /* Trap type code for powerpc */
> >>>+ unsigned char signo; /* Signal that we map this trap into
> >>>*/
> >>>+} hard_trap_info[] = {
> >>>+#if defined(CONFIG_40x)
> >>>+ { 0x100, SIGINT }, /* critical input interrupt */
> >>>+ { 0x200, SIGSEGV }, /* machine check */
> >>>+ { 0x300, SIGSEGV }, /* data storage */
> >>>+ { 0x400, SIGBUS }, /* instruction storage */
> >>>+ { 0x500, SIGINT }, /* interrupt */
> >>>+ { 0x600, SIGBUS }, /* alignment */
> >>>+ { 0x700, SIGILL }, /* program */
> >>>+ { 0x800, SIGILL }, /* reserved */
> >>>+ { 0x900, SIGILL }, /* reserved */
> >>>+ { 0xa00, SIGILL }, /* reserved */
> >>>+ { 0xb00, SIGILL }, /* reserved */
> >>>+ { 0xc00, SIGCHLD }, /* syscall */
> >>>+ { 0xd00, SIGILL }, /* reserved */
> >>>+ { 0xe00, SIGILL }, /* reserved */
> >>>+ { 0xf00, SIGILL }, /* reserved */
> >>>+ { 0x2000, SIGTRAP}, /* debug */
> >>>+#else
> >>>+ { 0x200, SIGSEGV }, /* machine check */
> >>>+ { 0x300, SIGSEGV }, /* address error (store) */
> >>>+ { 0x400, SIGBUS }, /* instruction bus error */
> >>>+ { 0x500, SIGINT }, /* interrupt */
> >>>+ { 0x600, SIGBUS }, /* alingment */
> >>>+ { 0x700, SIGTRAP }, /* breakpoint trap */
> >>>+ { 0x800, SIGFPE }, /* fpu unavail */
> >>>+ { 0x900, SIGALRM }, /* decrementer */
> >>>+ { 0xa00, SIGILL }, /* reserved */
> >>>+ { 0xb00, SIGILL }, /* reserved */
> >>>+ { 0xc00, SIGCHLD }, /* syscall */
> >>>+ { 0xd00, SIGTRAP }, /* single-step/watch */
> >>>+ { 0xe00, SIGFPE }, /* fp assist */
> >>>+#endif
> >>>+ { 0, 0} /* Must be last */
> >>>+};
> >>>+
> >>>+static int computeSignal(unsigned int tt)
> >>>+{
> >>>+ struct hard_trap_info *ht;
> >>>+
> >>>+ for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
> >>>+ if (ht->tt == tt)
> >>>+ return ht->signo;
> >>>+
> >>>+ return SIGHUP; /* default for things we don't know about */
> >>>+}
> >>>+
> >>>/*
> >>>* 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.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* 2.6.1: usblp.c: usblp0: nonzero read/write bulk status received
From: Ulrich Schenck @ 2004-01-26 21:35 UTC (permalink / raw)
To: linux-kernel
Hello,
I have a problem with printing. I always get the following messages when I try
to print.
Jan 26 22:09:18 castle kernel: drivers/usb/class/usblp.c: usblp0: USB
Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x043D pid 0x000C
Jan 26 22:10:04 castle kernel: drivers/usb/class/usblp.c: usblp0: nonzero
read/write bulk status received: -84
Jan 26 22:10:04 castle kernel: drivers/usb/class/usblp.c: usblp0: nonzero
read/write bulk status received: -110
Google got some old hits, but no help...
Please CC me, because I am not subscribed.
Please tell me, if you need further information, because I don`t know, what you
need.
Thanks in advance,
Ulrich
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: Tom Rini @ 2004-01-26 21:32 UTC (permalink / raw)
To: Amit S. Kale
Cc: Powerpc Linux, Linux Kernel, KGDB bugreports, George Anzinger
In-Reply-To: <20040121192128.GV13454@stop.crashing.org>
On Wed, Jan 21, 2004 at 12:21:28PM -0700, Tom Rini wrote:
> On Wed, Jan 21, 2004 at 11:42:17AM -0700, Tom Rini wrote:
> > On Wed, Jan 21, 2004 at 10:23:12PM +0530, Amit S. Kale wrote:
> >
> > > Hi,
> > >
> > > Here it is: ppc kgdb from timesys kernel is available at
> > > http://kgdb.sourceforge.net/kgdb-2/linux-2.6.1-kgdb-2.1.0.tar.bz2
> > >
> > > This is my attempt at extracting kgdb from TimeSys kernel. It works well in
> > > TimeSys kernel, so blame me if above patch doesn't work.
> >
> > Okay, here's my first patch against this.
>
> And dependant upon this is a patch to fixup the rest of the common PPC
> code, as follows:
Relative to this, due to the PPC changes is the following:
- In kgdb_handle_exception, memset remcomOutBuffer twice, instead of
continiously throwing in NULLs around.
- Remove a KERN_CRIT from the printk while waiting for kgdb to connect
(it's not needed there).
- Switch the initial packet from an 'S' packet (followed by a p for the
thread ID) to a 'T' packet.
This is tested on PPC and i386 (lightly).
include/asm-i386/kgdb.h | 4 ++
include/asm-ppc/kgdb.h | 3 +
include/asm-x86_64/kgdb.h | 4 ++
kernel/kgdbstub.c | 70 ++++++++++++++++++++++------------------------
4 files changed, 45 insertions(+), 36 deletions(-)
--- 1.1/include/asm-i386/kgdb.h Wed Jan 21 10:13:15 2004
+++ edited/include/asm-i386/kgdb.h Mon Jan 26 12:15:22 2004
@@ -43,6 +43,10 @@
_GS /* 15 */
};
+#define PC_REGNUM _PC /* Program Counter */
+#define SP_REGNUM _ESP /* Stack Pointer */
+#define PTRACE_PC eip /* Program Counter, in ptrace regs. */
+
#define BREAKPOINT() asm(" int $3");
#define BREAK_INSTR_SIZE 1
--- 1.5/include/asm-ppc/kgdb.h Wed Jan 21 12:21:23 2004
+++ edited/include/asm-ppc/kgdb.h Mon Jan 26 12:16:39 2004
@@ -19,6 +19,9 @@
#define NUMREGBYTES (MAXREG * sizeof(int))
#define BUFMAX ((NUMREGBYTES * 2) + 512)
#define OUTBUFMAX ((NUMREGBYTES * 2) + 512)
+#define PC_REGNUM 64
+#define SP_REGNUM 1
+#define PTRACE_PC nip /* Program Counter, in ptrace regs. */
#define BREAKPOINT() asm(".long 0x7d821008") /* twge r2, r2 */
/* Things specific to the gen550 backend. */
--- 1.1/include/asm-x86_64/kgdb.h Wed Jan 21 10:13:16 2004
+++ edited/include/asm-x86_64/kgdb.h Mon Jan 26 12:16:15 2004
@@ -44,6 +44,10 @@
_PS,
_LASTREG=_PS };
+#define PC_REGNUM _PC /* Program Counter */
+#define SP_REGNUM _RSP /* Stack Pointer */
+#define PTRACE_PC rip /* Program Counter, in ptrace regs. */
+
/* Number of bytes of registers. */
#define NUMREGBYTES (_LASTREG*8)
--- 1.2/kernel/kgdbstub.c Wed Jan 21 12:21:23 2004
+++ edited/kernel/kgdbstub.c Mon Jan 26 12:17:02 2004
@@ -615,6 +615,9 @@
* need one here */
procindebug[smp_processor_id()] = 1;
+ /* Clear the out buffer. */
+ memset(remcomOutBuffer, 0, sizeof(remcomOutBuffer));
+
/* Master processor is completely in the debugger */
if (kgdb_ops->post_master_code)
kgdb_ops->post_master_code(linux_regs, exVector, err_code);
@@ -624,9 +627,7 @@
if(remcomInBuffer[0] == 'H' && remcomInBuffer[1] =='c') {
remove_all_break();
atomic_set(&kgdb_killed_or_detached, 0);
- remcomOutBuffer[0] = 'O';
- remcomOutBuffer[1] = 'K';
- remcomOutBuffer[2] = 0;
+ strcpy(remcomOutBuffer, "OK");
}
else
return 1;
@@ -634,13 +635,25 @@
else {
/* reply to host that an exception has occurred */
- remcomOutBuffer[0] = 'S';
- remcomOutBuffer[1] = hexchars[signo >> 4];
- remcomOutBuffer[2] = hexchars[signo % 16];
- remcomOutBuffer[3] = 'p';
-
+ ptr = remcomOutBuffer;
+ *ptr++ = 'T';
+ *ptr++ = hexchars[(signo >> 4) % 16];
+ *ptr++ = hexchars[signo % 16];
+ *ptr++ = hexchars[(PC_REGNUM >> 4) % 16];
+ *ptr++ = hexchars[PC_REGNUM % 16];
+ *ptr++ = ':';
+ ptr = kgdb_mem2hex((char *)&linux_regs->PTRACE_PC, ptr, 4, 0);
+ *ptr++ = ';';
+ *ptr++ = hexchars[SP_REGNUM >> 4];
+ *ptr++ = hexchars[SP_REGNUM & 0xf];
+ *ptr++ = ':';
+ ptr = kgdb_mem2hex(((char *)linux_regs) + SP_REGNUM * 4, ptr,
+ 4, 0);
+ *ptr++ = ';';
+ ptr += strlen(strcpy(ptr, "thread:"));
int_to_threadref(&thref, shadow_pid(current->pid));
- *pack_threadid(remcomOutBuffer + 4, &thref) = 0;
+ ptr = pack_threadid(ptr, &thref);
+ *ptr++ = ';';
}
putpacket(remcomOutBuffer, 0);
kgdb_connected = 1;
@@ -651,8 +664,10 @@
while (1) {
int bpt_type = 0;
error = 0;
- remcomOutBuffer[0] = 0;
- remcomOutBuffer[1] = 0;
+
+ /* Clear the out buffer. */
+ memset(remcomOutBuffer, 0, sizeof(remcomOutBuffer));
+
getpacket(remcomInBuffer);
#if KGDB_DEBUG
@@ -666,7 +681,6 @@
remcomOutBuffer[0] = 'S';
remcomOutBuffer[1] = hexchars[signo >> 4];
remcomOutBuffer[2] = hexchars[signo % 16];
- remcomOutBuffer[3] = 0;
break;
case 'g': /* return the value of the CPU registers */
@@ -764,9 +778,7 @@
* continue.
*/
case 'D':
- remcomOutBuffer[0] = 'O';
- remcomOutBuffer[1] = 'K';
- remcomOutBuffer[2] = '\0';
+ strcpy(remcomOutBuffer, "OK");
remove_all_break();
putpacket(remcomOutBuffer, 0);
kgdb_connected = 0;
@@ -804,19 +816,16 @@
i++;
}
}
- *(--ptr) = '\0';
break;
case 'C':
/* Current thread id */
- remcomOutBuffer[0] = 'Q';
- remcomOutBuffer[1] = 'C';
+ strcpy(remcomOutBuffer, "QC");
threadid = shadow_pid(current->pid);
int_to_threadref(&thref, threadid);
pack_threadid(remcomOutBuffer + 2, &thref);
- remcomOutBuffer[18] = '\0';
break;
case 'E':
@@ -829,7 +838,6 @@
case 'T':
if (memcmp(remcomInBuffer+1, "ThreadExtraInfo,",16))
{
- remcomOutBuffer[0] = 0;
strcpy(remcomOutBuffer, "E05");
break;
}
@@ -872,14 +880,11 @@
thread = getthread(linux_regs, threadid);
if (!thread && threadid > 0) {
remcomOutBuffer[0] = 'E';
- remcomOutBuffer[1] = '\0';
break;
}
kgdb_usethread = thread;
kgdb_usethreadid = threadid;
- remcomOutBuffer[0] = 'O';
- remcomOutBuffer[1] = 'K';
- remcomOutBuffer[2] = '\0';
+ strcpy(remcomOutBuffer, "OK");
break;
case 'c':
@@ -892,14 +897,11 @@
thread = getthread(linux_regs, threadid);
if (!thread && threadid > 0) {
remcomOutBuffer[0] = 'E';
- remcomOutBuffer[1] = '\0';
break;
}
kgdb_contthread = thread;
}
- remcomOutBuffer[0] = 'O';
- remcomOutBuffer[1] = 'K';
- remcomOutBuffer[2] = '\0';
+ strcpy(remcomOutBuffer, "OK");
break;
}
break;
@@ -909,14 +911,10 @@
ptr = &remcomInBuffer[1];
kgdb_hexToLong(&ptr, &threadid);
thread = getthread(linux_regs, threadid);
- if (thread) {
- remcomOutBuffer[0] = 'O';
- remcomOutBuffer[1] = 'K';
- remcomOutBuffer[2] = '\0';
- } else {
+ if (thread)
+ strcpy(remcomOutBuffer, "OK");
+ else
remcomOutBuffer[0] = 'E';
- remcomOutBuffer[1] = '\0';
- }
break;
case 'z':
case 'Z':
@@ -1127,7 +1125,7 @@
*/
printk(KERN_CRIT "Waiting for connection from remote gdb... ");
breakpoint() ;
- printk(KERN_CRIT "Connected.\n");
+ printk("Connected.\n");
}
#ifdef CONFIG_KGDB_CONSOLE
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PNP depends on ISA ? (2.6.2-rc2
From: Adam Belay @ 2004-01-26 16:17 UTC (permalink / raw)
To: Micha Feigin; +Cc: linux-kernel
In-Reply-To: <20040126193144.GC2004@luna.mooo.com>
On Mon, Jan 26, 2004 at 09:31:44PM +0200, Micha Feigin wrote:
> I was wondering why pnp depends on isa being selected in 2.6.2-rc2, is
> pnp really only relevant to isa? What happens with pci etc. ?
> This may explain why using pnpbios locks up my machine (at least as of 2.6.0-test9).
Yes, it only is related to isa devices, but they include onboard devices
such as serial ports. It will, however, prevent resource conflicts
between pci and system devices, especially with unusual configurations.
Does using pnpbios cause your machine to lockup at boot? If so, around
where does it occur? DMI information would also be useful for blacklisting
purposes.
Thanks,
Adam
^ permalink raw reply
* Re: [patch] 2.6.2-rc2: link error with IrDA drivers
From: David S. Miller @ 2004-01-26 21:15 UTC (permalink / raw)
To: jt, jt; +Cc: bunk, linux-kernel, jgarzik, linux-net, akpm
In-Reply-To: <20040126211603.GA17646@bougret.hpl.hp.com>
From: Jean Tourrilhes <jt@bougret.hpl.hp.com>
Date: Mon, 26 Jan 2004 13:16:03 -0800
I've just sent the following patch to Andrew (following his
bug report), and I think it's slightly better and safer. Sorry I
forgot to cc you.
In my personal opinion it's worse not better.
Andrew, back out jt's version of the fix from your tree, I'll
send Linus the correct fix (attached below). I verified that
nothing external wants to get at any of these symbols.
Thanks everyone.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1520 -> 1.1521
# drivers/net/irda/via-ircc.c 1.6 -> 1.7
# drivers/net/irda/nsc-ircc.c 1.29 -> 1.30
# drivers/net/irda/girbil.c 1.8 -> 1.9
# drivers/net/irda/ep7211_ir.c 1.5 -> 1.6
# drivers/net/irda/litelink-sir.c 1.1 -> 1.2
# drivers/net/irda/tekram-sir.c 1.4 -> 1.5
# drivers/net/irda/act200l-sir.c 1.1 -> 1.2
# drivers/net/irda/w83977af_ir.c 1.23 -> 1.24
# drivers/net/irda/ali-ircc.c 1.24 -> 1.25
# drivers/net/irda/ma600.c 1.7 -> 1.8
# drivers/net/irda/girbil-sir.c 1.1 -> 1.2
# drivers/net/irda/act200l.c 1.7 -> 1.8
# drivers/net/irda/esi.c 1.6 -> 1.7
# drivers/net/irda/litelink.c 1.6 -> 1.7
# drivers/net/irda/tekram.c 1.9 -> 1.10
# drivers/net/irda/actisys-sir.c 1.4 -> 1.5
# drivers/net/irda/smsc-ircc2.c 1.8 -> 1.9
# drivers/net/irda/ma600-sir.c 1.1 -> 1.2
# drivers/net/irda/irport.c 1.21 -> 1.22
# drivers/net/irda/mcp2120-sir.c 1.1 -> 1.2
# drivers/net/irda/old_belkin-sir.c 1.1 -> 1.2
# drivers/net/irda/old_belkin.c 1.8 -> 1.9
# drivers/net/irda/mcp2120.c 1.7 -> 1.8
# drivers/net/irda/actisys.c 1.9 -> 1.10
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/01/26 davem@nuts.ninka.net 1.1521
# [IRDA]: Mark init/exit functions of drivers static to fix build.
# --------------------------------------------
#
diff -Nru a/drivers/net/irda/act200l-sir.c b/drivers/net/irda/act200l-sir.c
--- a/drivers/net/irda/act200l-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/act200l-sir.c Mon Jan 26 13:20:40 2004
@@ -93,12 +93,12 @@
.set_speed = act200l_change_speed,
};
-int __init act200l_init(void)
+static int __init act200l_init(void)
{
return irda_register_dongle(&act200l);
}
-void __exit act200l_cleanup(void)
+static void __exit act200l_cleanup(void)
{
irda_unregister_dongle(&act200l);
}
diff -Nru a/drivers/net/irda/act200l.c b/drivers/net/irda/act200l.c
--- a/drivers/net/irda/act200l.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/act200l.c Mon Jan 26 13:20:40 2004
@@ -92,12 +92,12 @@
.owner = THIS_MODULE,
};
-int __init act200l_init(void)
+static int __init act200l_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit act200l_cleanup(void)
+static void __exit act200l_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/actisys-sir.c b/drivers/net/irda/actisys-sir.c
--- a/drivers/net/irda/actisys-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/actisys-sir.c Mon Jan 26 13:20:40 2004
@@ -89,7 +89,7 @@
.set_speed = actisys_change_speed,
};
-int __init actisys_sir_init(void)
+static int __init actisys_sir_init(void)
{
int ret;
@@ -107,7 +107,7 @@
return 0;
}
-void __exit actisys_sir_cleanup(void)
+static void __exit actisys_sir_cleanup(void)
{
/* We have to remove both dongles */
irda_unregister_dongle(&act220l_plus);
diff -Nru a/drivers/net/irda/actisys.c b/drivers/net/irda/actisys.c
--- a/drivers/net/irda/actisys.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/actisys.c Mon Jan 26 13:20:40 2004
@@ -91,7 +91,7 @@
* So, we register a dongle of each sort and let irattach
* pick the right one...
*/
-int __init actisys_init(void)
+static int __init actisys_init(void)
{
int ret;
@@ -108,7 +108,7 @@
return 0;
}
-void __exit actisys_cleanup(void)
+static void __exit actisys_cleanup(void)
{
/* We have to remove both dongles */
irda_device_unregister_dongle(&dongle);
diff -Nru a/drivers/net/irda/ali-ircc.c b/drivers/net/irda/ali-ircc.c
--- a/drivers/net/irda/ali-ircc.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/ali-ircc.c Mon Jan 26 13:20:40 2004
@@ -133,7 +133,7 @@
* Initialize chip. Find out whay kinds of chips we are dealing with
* and their configuation registers address
*/
-int __init ali_ircc_init(void)
+static int __init ali_ircc_init(void)
{
ali_chip_t *chip;
chipio_t info;
diff -Nru a/drivers/net/irda/ep7211_ir.c b/drivers/net/irda/ep7211_ir.c
--- a/drivers/net/irda/ep7211_ir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/ep7211_ir.c Mon Jan 26 13:20:40 2004
@@ -97,7 +97,7 @@
* Initialize EP7211 I/R module
*
*/
-int __init ep7211_ir_init(void)
+static int __init ep7211_ir_init(void)
{
return irda_device_register_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/esi.c b/drivers/net/irda/esi.c
--- a/drivers/net/irda/esi.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/esi.c Mon Jan 26 13:20:40 2004
@@ -52,12 +52,12 @@
.owner = THIS_MODULE,
};
-int __init esi_init(void)
+static int __init esi_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit esi_cleanup(void)
+static void __exit esi_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/girbil-sir.c b/drivers/net/irda/girbil-sir.c
--- a/drivers/net/irda/girbil-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/girbil-sir.c Mon Jan 26 13:20:40 2004
@@ -72,12 +72,12 @@
.set_speed = girbil_change_speed,
};
-int __init girbil_init(void)
+static int __init girbil_init(void)
{
return irda_register_dongle(&girbil);
}
-void __exit girbil_cleanup(void)
+static void __exit girbil_cleanup(void)
{
irda_unregister_dongle(&girbil);
}
diff -Nru a/drivers/net/irda/girbil.c b/drivers/net/irda/girbil.c
--- a/drivers/net/irda/girbil.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/girbil.c Mon Jan 26 13:20:40 2004
@@ -71,12 +71,12 @@
.owner = THIS_MODULE,
};
-int __init girbil_init(void)
+static int __init girbil_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit girbil_cleanup(void)
+static void __exit girbil_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/irport.c b/drivers/net/irda/irport.c
--- a/drivers/net/irda/irport.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/irport.c Mon Jan 26 13:20:40 2004
@@ -98,7 +98,7 @@
EXPORT_SYMBOL(irport_net_open);
EXPORT_SYMBOL(irport_net_close);
-int __init irport_init(void)
+static int __init irport_init(void)
{
int i;
diff -Nru a/drivers/net/irda/litelink-sir.c b/drivers/net/irda/litelink-sir.c
--- a/drivers/net/irda/litelink-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/litelink-sir.c Mon Jan 26 13:20:40 2004
@@ -64,12 +64,12 @@
.set_speed = litelink_change_speed,
};
-int __init litelink_sir_init(void)
+static int __init litelink_sir_init(void)
{
return irda_register_dongle(&litelink);
}
-void __exit litelink_sir_cleanup(void)
+static void __exit litelink_sir_cleanup(void)
{
irda_unregister_dongle(&litelink);
}
diff -Nru a/drivers/net/irda/litelink.c b/drivers/net/irda/litelink.c
--- a/drivers/net/irda/litelink.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/litelink.c Mon Jan 26 13:20:40 2004
@@ -56,12 +56,12 @@
.owner = THIS_MODULE,
};
-int __init litelink_init(void)
+static int __init litelink_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit litelink_cleanup(void)
+static void __exit litelink_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/ma600-sir.c b/drivers/net/irda/ma600-sir.c
--- a/drivers/net/irda/ma600-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/ma600-sir.c Mon Jan 26 13:20:40 2004
@@ -66,13 +66,13 @@
};
-int __init ma600_sir_init(void)
+static int __init ma600_sir_init(void)
{
IRDA_DEBUG(2, "%s()\n", __FUNCTION__);
return irda_register_dongle(&ma600);
}
-void __exit ma600_sir_cleanup(void)
+static void __exit ma600_sir_cleanup(void)
{
IRDA_DEBUG(2, "%s()\n", __FUNCTION__);
irda_unregister_dongle(&ma600);
diff -Nru a/drivers/net/irda/ma600.c b/drivers/net/irda/ma600.c
--- a/drivers/net/irda/ma600.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/ma600.c Mon Jan 26 13:20:40 2004
@@ -82,13 +82,13 @@
.owner = THIS_MODULE,
};
-int __init ma600_init(void)
+static int __init ma600_init(void)
{
IRDA_DEBUG(2, "%s()\n", __FUNCTION__);
return irda_device_register_dongle(&dongle);
}
-void __exit ma600_cleanup(void)
+static void __exit ma600_cleanup(void)
{
IRDA_DEBUG(2, "%s()\n", __FUNCTION__);
irda_device_unregister_dongle(&dongle);
diff -Nru a/drivers/net/irda/mcp2120-sir.c b/drivers/net/irda/mcp2120-sir.c
--- a/drivers/net/irda/mcp2120-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/mcp2120-sir.c Mon Jan 26 13:20:40 2004
@@ -49,12 +49,12 @@
.set_speed = mcp2120_change_speed,
};
-int __init mcp2120_init(void)
+static int __init mcp2120_init(void)
{
return irda_register_dongle(&mcp2120);
}
-void __exit mcp2120_cleanup(void)
+static void __exit mcp2120_cleanup(void)
{
irda_unregister_dongle(&mcp2120);
}
diff -Nru a/drivers/net/irda/mcp2120.c b/drivers/net/irda/mcp2120.c
--- a/drivers/net/irda/mcp2120.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/mcp2120.c Mon Jan 26 13:20:40 2004
@@ -48,12 +48,12 @@
.owner = THIS_MODULE,
};
-int __init mcp2120_init(void)
+static int __init mcp2120_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit mcp2120_cleanup(void)
+static void __exit mcp2120_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/nsc-ircc.c b/drivers/net/irda/nsc-ircc.c
--- a/drivers/net/irda/nsc-ircc.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/nsc-ircc.c Mon Jan 26 13:20:40 2004
@@ -155,7 +155,7 @@
* Initialize chip. Just try to find out how many chips we are dealing with
* and where they are
*/
-int __init nsc_ircc_init(void)
+static int __init nsc_ircc_init(void)
{
chipio_t info;
nsc_chip_t *chip;
diff -Nru a/drivers/net/irda/old_belkin-sir.c b/drivers/net/irda/old_belkin-sir.c
--- a/drivers/net/irda/old_belkin-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/old_belkin-sir.c Mon Jan 26 13:20:40 2004
@@ -78,12 +78,12 @@
.set_speed = old_belkin_change_speed,
};
-int __init old_belkin_init(void)
+static int __init old_belkin_init(void)
{
return irda_register_dongle(&old_belkin);
}
-void __exit old_belkin_cleanup(void)
+static void __exit old_belkin_cleanup(void)
{
irda_unregister_dongle(&old_belkin);
}
diff -Nru a/drivers/net/irda/old_belkin.c b/drivers/net/irda/old_belkin.c
--- a/drivers/net/irda/old_belkin.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/old_belkin.c Mon Jan 26 13:20:40 2004
@@ -82,12 +82,12 @@
.owner = THIS_MODULE,
};
-int __init old_belkin_init(void)
+static int __init old_belkin_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit old_belkin_cleanup(void)
+static void __exit old_belkin_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
--- a/drivers/net/irda/smsc-ircc2.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/smsc-ircc2.c Mon Jan 26 13:20:40 2004
@@ -322,7 +322,7 @@
* Initialize chip. Just try to find out how many chips we are dealing with
* and where they are
*/
-int __init smsc_ircc_init(void)
+static int __init smsc_ircc_init(void)
{
int ret=-ENODEV;
@@ -1727,7 +1727,7 @@
return 0;
}
-void __exit smsc_ircc_cleanup(void)
+static void __exit smsc_ircc_cleanup(void)
{
int i;
diff -Nru a/drivers/net/irda/tekram-sir.c b/drivers/net/irda/tekram-sir.c
--- a/drivers/net/irda/tekram-sir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/tekram-sir.c Mon Jan 26 13:20:40 2004
@@ -59,7 +59,7 @@
.set_speed = tekram_change_speed,
};
-int __init tekram_sir_init(void)
+static int __init tekram_sir_init(void)
{
if (tekram_delay < 1 || tekram_delay > 500)
tekram_delay = 200;
@@ -68,7 +68,7 @@
return irda_register_dongle(&tekram);
}
-void __exit tekram_sir_cleanup(void)
+static void __exit tekram_sir_cleanup(void)
{
irda_unregister_dongle(&tekram);
}
diff -Nru a/drivers/net/irda/tekram.c b/drivers/net/irda/tekram.c
--- a/drivers/net/irda/tekram.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/tekram.c Mon Jan 26 13:20:40 2004
@@ -52,12 +52,12 @@
.owner = THIS_MODULE,
};
-int __init tekram_init(void)
+static int __init tekram_init(void)
{
return irda_device_register_dongle(&dongle);
}
-void __exit tekram_cleanup(void)
+static void __exit tekram_cleanup(void)
{
irda_device_unregister_dongle(&dongle);
}
diff -Nru a/drivers/net/irda/via-ircc.c b/drivers/net/irda/via-ircc.c
--- a/drivers/net/irda/via-ircc.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/via-ircc.c Mon Jan 26 13:20:40 2004
@@ -145,7 +145,7 @@
*
* Initialize chip. Just find out chip type and resource.
*/
-int __init via_ircc_init(void)
+static int __init via_ircc_init(void)
{
int rc;
diff -Nru a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
--- a/drivers/net/irda/w83977af_ir.c Mon Jan 26 13:20:40 2004
+++ b/drivers/net/irda/w83977af_ir.c Mon Jan 26 13:20:40 2004
@@ -110,7 +110,7 @@
* Initialize chip. Just try to find out how many chips we are dealing with
* and where they are
*/
-int __init w83977af_init(void)
+static int __init w83977af_init(void)
{
int i;
@@ -129,7 +129,7 @@
* Close all configured chips
*
*/
-void __exit w83977af_cleanup(void)
+static void __exit w83977af_cleanup(void)
{
int i;
^ permalink raw reply
* Re: Implementation of read( )
From: Steven Smith @ 2004-01-26 21:28 UTC (permalink / raw)
To: Vineet Joglekar; +Cc: linux-c-programming
In-Reply-To: <20040126201655.DBEB51E447@xprdmailfe25.nwk.excite.com>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
> I have read that read() makes the kernel invoke sys_read()
Yup.
> 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?
Nowadays, most programs will use glibc's implementation of read, which
is in the glibc source (sysdeps/unix/sysv/linux/i386/syscall.S,
mostly). There is, however, a macro in asm/unistd.h in the kernel
source pool which will do the basics for you. The code goes like
this:
#include <asm/unistd.h>
#define __NR_private_read __NR_read
_syscall3(int, private_read, int, fd, char *, buf, size_t, size);
Calling private_read will then make the read system call directly
without going through libc. Strictly speaking, it is valid to just
redefine read in the obvious way, but that gets horribly confusing.
The alternative approach is to call your function read, taking
advantage of the fact that a normal symbol will override one of the
weak symbols in libc, and then just call __libc_read when you need to
use the libc implementation.
Steven Smith,
sos22@cam.ac.uk
[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: PPC KGDB changes and some help?
From: George Anzinger @ 2004-01-26 21:27 UTC (permalink / raw)
To: Tom Rini; +Cc: Amit S. Kale, Powerpc Linux, Linux Kernel, KGDB bugreports
In-Reply-To: <20040126204631.GB32525@stop.crashing.org>
Tom Rini wrote:
> On Fri, Jan 23, 2004 at 03:38:39PM -0800, George Anzinger wrote:
>
>>Tom Rini wrote:
>>
>>>On Thu, Jan 22, 2004 at 11:05:55AM -0700, Tom Rini wrote:
>>>[snip]
>>>
>>>
>>>>First up:
>>>>We need to call flush_instruction_cache() on a 'c' or 's' command.
>>>>arch/ppc/kernel/ppc-stub.c | 19 ++++++-------------
>>>>1 files changed, 6 insertions(+), 13 deletions(-)
>>>
>>>
>>>On tpo of this patch, there's the following:
>>>Put back some code to figure out what signal we're dealing with.
>>>
>>>arch/ppc/kernel/ppc-stub.c | 63
>>>++++++++++++++++++++++++++++++++++++++++++---
>>>1 files changed, 60 insertions(+), 3 deletions(-)
>>>--- 1.15/arch/ppc/kernel/ppc-stub.c Thu Jan 22 10:53:06 2004
>>>+++ edited/arch/ppc/kernel/ppc-stub.c Fri Jan 23 15:43:10 2004
>>>@@ -3,6 +3,7 @@
>>> *
>>> * PowerPC-specific bits to work with the common KGDB stub.
>>> *
>>>+ * 1998 (c) Michael AK Tesch (tesch@cs.wisc.edu)
>>> * 2003 (c) TimeSys Corporation
>>> * 2004 (c) MontaVista Software, Inc.
>>> * This file is licensed under the terms of the GNU General Public License
>>>@@ -19,13 +20,69 @@
>>>#include <asm/processor.h>
>>>#include <asm/machdep.h>
>>>
>>>+/* Convert the hardware trap type code to a unix signal number. */
>>>+/*
>>>+ * This table contains the mapping between PowerPC hardware trap types,
>>>and
>>>+ * signals, which are primarily what GDB understands.
>>>+ */
>>>+static struct hard_trap_info
>>>+{
>>>+ unsigned int tt; /* Trap type code for powerpc */
>>>+ unsigned char signo; /* Signal that we map this trap into
>>>*/
>>>+} hard_trap_info[] = {
>>>+#if defined(CONFIG_40x)
>>>+ { 0x100, SIGINT }, /* critical input interrupt */
>>>+ { 0x200, SIGSEGV }, /* machine check */
>>>+ { 0x300, SIGSEGV }, /* data storage */
>>>+ { 0x400, SIGBUS }, /* instruction storage */
>>>+ { 0x500, SIGINT }, /* interrupt */
>>>+ { 0x600, SIGBUS }, /* alignment */
>>>+ { 0x700, SIGILL }, /* program */
>>>+ { 0x800, SIGILL }, /* reserved */
>>>+ { 0x900, SIGILL }, /* reserved */
>>>+ { 0xa00, SIGILL }, /* reserved */
>>>+ { 0xb00, SIGILL }, /* reserved */
>>>+ { 0xc00, SIGCHLD }, /* syscall */
>>>+ { 0xd00, SIGILL }, /* reserved */
>>>+ { 0xe00, SIGILL }, /* reserved */
>>>+ { 0xf00, SIGILL }, /* reserved */
>>>+ { 0x2000, SIGTRAP}, /* debug */
>>>+#else
>>>+ { 0x200, SIGSEGV }, /* machine check */
>>>+ { 0x300, SIGSEGV }, /* address error (store) */
>>>+ { 0x400, SIGBUS }, /* instruction bus error */
>>>+ { 0x500, SIGINT }, /* interrupt */
>>>+ { 0x600, SIGBUS }, /* alingment */
>>>+ { 0x700, SIGTRAP }, /* breakpoint trap */
>>>+ { 0x800, SIGFPE }, /* fpu unavail */
>>>+ { 0x900, SIGALRM }, /* decrementer */
>>>+ { 0xa00, SIGILL }, /* reserved */
>>>+ { 0xb00, SIGILL }, /* reserved */
>>>+ { 0xc00, SIGCHLD }, /* syscall */
>>>+ { 0xd00, SIGTRAP }, /* single-step/watch */
>>>+ { 0xe00, SIGFPE }, /* fp assist */
>>>+#endif
>>>+ { 0, 0} /* Must be last */
>>>+};
>>>+
>>>+static int computeSignal(unsigned int tt)
>>>+{
>>>+ struct hard_trap_info *ht;
>>>+
>>>+ for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
>>>+ if (ht->tt == tt)
>>>+ return ht->signo;
>>>+
>>>+ return SIGHUP; /* default for things we don't know about */
>>>+}
>>>+
>>>/*
>>> * 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?
--
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
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.