Re: [PATCH] PPS: Restore lost capture-clear option to pps-gpio module.
Yo Jan! On Thu, 09 Apr 2015 15:05:09 +0200 Jan Lübbe wrote: > Hi Gary, > > On Do, 2015-04-02 at 12:21 -0700, Gary E. Miller wrote: > > In the conversion from platform to device tree the capture-clear > > option was lost. > > > > capture-clear is needed so that time_pps_fetch() will report both > > edges of each PPS pulse. Both edges are needed so that userland > > programs, like gpsd, can autodetect the leading and trailing PPS > > edges. > > This is intentional. The userspace program can configure which edges > it wants to capture at runtime. Yes, on pps-ldisc, but no on pps-gpio. If you think I am wrong then please show me how I can do that in my userspace program. I have talked to several experts that could not figure out how to do so. They all started with the same assertion as yours. The time_pps_setcap() function call will not work to do so because the PPS_CAPTUREASSERT is locked out before time_pps_getcap(). You can easily verify this with the ppstest program on a Raspberry Pi running Debian Wheezy using an Adafruit GPS. Notice that info->catpure_clear can ONLY be set one place in the entire driver, and that place is during platform probing. pps-gpio.c line 110. No other place. Without info->capture_clear it is not possible to capture the clear edge. Check pps-gpio.c lines 68 and 82. I would be happy to provide you ssh access to the test platform if you think you can prove me wrong. I have test programs I can show you that demonstrate this. > Only the polarity > (assert-falling-edge) is actually determined by the hardware and must > be described in the device tree. Now, but when it was a platform driver the capture assert could also be selected in the platform hardware description. I'm just trying to restore lost functionality. If instead you would be in favor of always allowing capture assert that would be good as well. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PPS: Restore lost capture-clear option to pps-gpio module.
Yo Jan! On Thu, 09 Apr 2015 15:05:09 +0200 Jan Lübbe j...@pengutronix.de wrote: Hi Gary, On Do, 2015-04-02 at 12:21 -0700, Gary E. Miller wrote: In the conversion from platform to device tree the capture-clear option was lost. capture-clear is needed so that time_pps_fetch() will report both edges of each PPS pulse. Both edges are needed so that userland programs, like gpsd, can autodetect the leading and trailing PPS edges. This is intentional. The userspace program can configure which edges it wants to capture at runtime. Yes, on pps-ldisc, but no on pps-gpio. If you think I am wrong then please show me how I can do that in my userspace program. I have talked to several experts that could not figure out how to do so. They all started with the same assertion as yours. The time_pps_setcap() function call will not work to do so because the PPS_CAPTUREASSERT is locked out before time_pps_getcap(). You can easily verify this with the ppstest program on a Raspberry Pi running Debian Wheezy using an Adafruit GPS. Notice that info-catpure_clear can ONLY be set one place in the entire driver, and that place is during platform probing. pps-gpio.c line 110. No other place. Without info-capture_clear it is not possible to capture the clear edge. Check pps-gpio.c lines 68 and 82. I would be happy to provide you ssh access to the test platform if you think you can prove me wrong. I have test programs I can show you that demonstrate this. Only the polarity (assert-falling-edge) is actually determined by the hardware and must be described in the device tree. Now, but when it was a platform driver the capture assert could also be selected in the platform hardware description. I'm just trying to restore lost functionality. If instead you would be in favor of always allowing capture assert that would be good as well. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPS: Restore lost capture-clear option to pps-gpio module.
In the conversion from platform to device tree the capture-clear
option was lost.
capture-clear is needed so that time_pps_fetch() will report both
edges of each PPS pulse. Both edges are needed so that userland
programs, like gpsd, can autodetect the leading and trailing PPS
edges.
Signed-off-by: Gary E. Miller
Fixes: c5dbcf8b70b5 ("pps-gpio: add device-tree binding and support")
Cc: Ricardo Martins
Cc: James Nuss
Cc: Jan Luebbe
Acked-by: Rodolfo Giometti
> ---`
---
Documentation/devicetree/bindings/pps/pps-gpio.txt | 2 ++
drivers/pps/clients/pps-gpio.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
b/Documentation/devicetree/bindings/pps/pps-gpio.txt
index 40bf9c3..98f8898 100644
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- assert-falling-edge: when present, assert is indicated by a falling edge
(instead of by a rising edge)
+- capture-clear: when present, also capture the clear edge
Example:
pps {
@@ -17,4 +18,5 @@ Example:
gpios = < 6 0>;
assert-falling-edge;
+ capture-clear;
};
diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c
index 333ad7d..dc4a71c 100644
--- a/drivers/pps/clients/pps-gpio.c
+++ b/drivers/pps/clients/pps-gpio.c
@@ -119,6 +119,8 @@ static int pps_gpio_probe(struct platform_device *pdev)
if (of_get_property(np, "assert-falling-edge", NULL))
data->assert_falling_edge = true;
+ if (of_get_property(np, "capture-clear", NULL))
+ data->capture_clear = true;
}
/* GPIO setup */
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPS: Restore lost capture-clear option to pps-gpio module.
In the conversion from platform to device tree the capture-clear
option was lost.
capture-clear is needed so that time_pps_fetch() will report both
edges of each PPS pulse. Both edges are needed so that userland
programs, like gpsd, can autodetect the leading and trailing PPS
edges.
Signed-off-by: Gary E. Miller g...@rellim.com
Fixes: c5dbcf8b70b5 (pps-gpio: add device-tree binding and support)
Cc: Ricardo Martins r...@fe.up.pt
Cc: James Nuss jamesn...@nanometrics.ca
Cc: Jan Luebbe j...@pengutronix.de
Acked-by: Rodolfo Giometti giome...@linux.it
---`
---
Documentation/devicetree/bindings/pps/pps-gpio.txt | 2 ++
drivers/pps/clients/pps-gpio.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
b/Documentation/devicetree/bindings/pps/pps-gpio.txt
index 40bf9c3..98f8898 100644
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- assert-falling-edge: when present, assert is indicated by a falling edge
(instead of by a rising edge)
+- capture-clear: when present, also capture the clear edge
Example:
pps {
@@ -17,4 +18,5 @@ Example:
gpios = gpio2 6 0;
assert-falling-edge;
+ capture-clear;
};
diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c
index 333ad7d..dc4a71c 100644
--- a/drivers/pps/clients/pps-gpio.c
+++ b/drivers/pps/clients/pps-gpio.c
@@ -119,6 +119,8 @@ static int pps_gpio_probe(struct platform_device *pdev)
if (of_get_property(np, assert-falling-edge, NULL))
data-assert_falling_edge = true;
+ if (of_get_property(np, capture-clear, NULL))
+ data-capture_clear = true;
}
/* GPIO setup */
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] Enable PPS reporting for USB serial devices
Yo Rodolfo! On Tue, 10 Sep 2013 09:31:05 +0200 Rodolfo Giometti wrote: > I have nothing against with this solution but consider that reporting > a PPS signal through USB bus may add unknown delays that may vanish > clock stability... as far as I know you should not use USB serial port > with PPS. Have you some statistics about clock stability in a real > implementation? gpsd project has been using PPS over USB 1.1 for over a year. Typical accuracy and repeatability in the range of +/- 1 milliSec. This is much better than you can get using simple ntp over gigabit ethernet to an adjacent stratum 1 server. Sure PPS over a local UART is 10 to 100 times better, but often PPS over USB is your best second choice. As serial ports become extinct it may become your best choice. RGDS GARY ------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 signature.asc Description: PGP signature
Re: [PATCH 0/5] Enable PPS reporting for USB serial devices
Yo Rodolfo! On Tue, 10 Sep 2013 09:31:05 +0200 Rodolfo Giometti giome...@enneenne.com wrote: I have nothing against with this solution but consider that reporting a PPS signal through USB bus may add unknown delays that may vanish clock stability... as far as I know you should not use USB serial port with PPS. Have you some statistics about clock stability in a real implementation? gpsd project has been using PPS over USB 1.1 for over a year. Typical accuracy and repeatability in the range of +/- 1 milliSec. This is much better than you can get using simple ntp over gigabit ethernet to an adjacent stratum 1 server. Sure PPS over a local UART is 10 to 100 times better, but often PPS over USB is your best second choice. As serial ports become extinct it may become your best choice. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 signature.asc Description: PGP signature
Re: IPsec support
Yo Eddie! On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > I checked 2.4.x source code but did not find any code for IPsec. Does > anyone know that current or latest Linux support IPsec? Or does anyone know > who is working on this ipv6 issue? www.freeswan.org RGDS GARY ------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPsec support
Yo Eddie! On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: I checked 2.4.x source code but did not find any code for IPsec. Does anyone know that current or latest Linux support IPsec? Or does anyone know who is working on this ipv6 issue? www.freeswan.org RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Yo Daniel! On Wed, 13 Jun 2001, Daniel Dickman wrote: > What I'd like to know is this -- will support for the i386, say, ever go > away? What if the hardware is no longer in existence/used by anyone? will > support stay in the kernel? There is an aweful lot of embedded Linux using 386 and 486 class devices. Just look at all those cheap NAT boxes at Frys. RGDS GARY ------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Yo Daniel! On Wed, 13 Jun 2001, Daniel Dickman wrote: What I'd like to know is this -- will support for the i386, say, ever go away? What if the hardware is no longer in existence/used by anyone? will support stay in the kernel? There is an aweful lot of embedded Linux using 386 and 486 class devices. Just look at all those cheap NAT boxes at Frys. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: SMBFS does not compile on test12-pre8
Yo All! Scott McDermott <[EMAIL PROTECTED]> convinced me the way to fix my problem with SMBFS was to use the INIT_LIST_HEAD() macro. This allows SMBFS to compile and may even be correct: --- sock.c.dist Mon Dec 11 15:26:56 2000 +++ sock.c Mon Dec 11 15:27:03 2000 @@ -163,7 +163,7 @@ found_data(sk); return; } - job->cb.next = NULL; // gem + INIT_LIST_HEAD(>cb.list); job->cb.sync = 0; job->cb.routine = smb_data_callback; job->cb.data = job; I am confused because INIT_LIST_HEAD() sets the next and prev pointers to point to the current structure. I just have to assume the list folks know what they are doing and that is why they made it a macro. Could someone that knows lists and/or smbfs look at this? RGDS GARY ----------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SMBFS does not compile on test12-pre8
Yo All! I just tried to compile SMBFS in test12-pre8. Here is the error message I get: make[3]: Entering directory `/u3/local/src/linux-2.4.0-test12-pre8/fs/smbfs' gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DSMBFS_PARANOIA -c -o sock.o sock.c sock.c: In function `smb_data_ready': sock.c:166: structure has no member named `next' make[3]: *** [sock.o] Error 1 This has worked in the recent past. This is the failing line 166 in fs/smbfs/sock.c: job->cb.next = NULL; It looks like tq_struct has been changed so that the tq_struct->next member is now tq_struct->list.next. So can we just delete line 166 in fs/smbfs/sock.c? Or do we still need to initialize next by changing line 166 to: job->cb.list.next = NULL. Ideas? RGDS GARY ------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SMBFS does not compile on test12-pre8
Yo All! I just tried to compile SMBFS in test12-pre8. Here is the error message I get: make[3]: Entering directory `/u3/local/src/linux-2.4.0-test12-pre8/fs/smbfs' gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DSMBFS_PARANOIA -c -o sock.o sock.c sock.c: In function `smb_data_ready': sock.c:166: structure has no member named `next' make[3]: *** [sock.o] Error 1 This has worked in the recent past. This is the failing line 166 in fs/smbfs/sock.c: job-cb.next = NULL; It looks like tq_struct has been changed so that the tq_struct-next member is now tq_struct-list.next. So can we just delete line 166 in fs/smbfs/sock.c? Or do we still need to initialize next by changing line 166 to: job-cb.list.next = NULL. Ideas? RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: SMBFS does not compile on test12-pre8
Yo All! Scott McDermott [EMAIL PROTECTED] convinced me the way to fix my problem with SMBFS was to use the INIT_LIST_HEAD() macro. This allows SMBFS to compile and may even be correct: --- sock.c.dist Mon Dec 11 15:26:56 2000 +++ sock.c Mon Dec 11 15:27:03 2000 @@ -163,7 +163,7 @@ found_data(sk); return; } - job-cb.next = NULL; // gem + INIT_LIST_HEAD(job-cb.list); job-cb.sync = 0; job-cb.routine = smb_data_callback; job-cb.data = job; I am confused because INIT_LIST_HEAD() sets the next and prev pointers to point to the current structure. I just have to assume the list folks know what they are doing and that is why they made it a macro. Could someone that knows lists and/or smbfs look at this? RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)
Yo Tigran! On Mon, 4 Dec 2000, Tigran Aivazian wrote: > Second attempt, the first one failed due to stupid setup of ISP and the > usage of mail-abuse.org which blocks anything that has no reverse DNS > lookup. Mail-abuse.org does nothing with reverse DNS.Many that hate spam choose to refuse mail with no reverse DNS on theire own. RGDS GARY ------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Attempt to hard link across filesystems results inun-unmountable filesystem (fwd)
Yo Tigran! On Mon, 4 Dec 2000, Tigran Aivazian wrote: Second attempt, the first one failed due to stupid setup of ISP and the usage of mail-abuse.org which blocks anything that has no reverse DNS lookup. Mail-abuse.org does nothing with reverse DNS.Many that hate spam choose to refuse mail with no reverse DNS on theire own. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox's e-mail address is hosed?
Yo Miles! Well I see 216.200.176.7 in ORBS: $ chk-rly 216.200.176.7 rbl.maps.vix.com => rss.maps.vix.com => dul.maps.vix.com => relays.orbs.org => 127.0.0.4 relays.orbs.org => untestable - above.net has multiple open relays and has blocked the ORBS tester. outputs.orbs.org => RGDS GARY ----------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Thu, 23 Nov 2000, Miles Lane wrote: > Okay, please explain why ORBS tells me it does *not* > identify my ISP's SMTP server as an open relay? > > mail.megapathdsl.net = 216.200.176.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox's e-mail address is hosed?
Yo Miles! Well I see 216.200.176.7 in ORBS: $ chk-rly 216.200.176.7 rbl.maps.vix.com = rss.maps.vix.com = dul.maps.vix.com = relays.orbs.org = 127.0.0.4 relays.orbs.org = untestable - above.net has multiple open relays and has blocked the ORBS tester. outputs.orbs.org = RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Thu, 23 Nov 2000, Miles Lane wrote: Okay, please explain why ORBS tells me it does *not* identify my ISP's SMTP server as an open relay? mail.megapathdsl.net = 216.200.176.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] deadlock fix
Yo All!
I see this patch did not make it into test11-pre1. Without it
raid1 and SMP do not work together. Please consider for test11-pre2.
RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
> > > Here it is.
> > >
> > > --- drivers/md/raid1.c.orgWed Oct 18 15:30:07 2000
> > > +++ drivers/md/raid1.cWed Oct 18 15:33:08 2000
> > > @@ -91,7 +91,8 @@
> > >
> > > static inline void raid1_free_bh(raid1_conf_t *conf, struct buffer_head *bh)
> > > {
> > > - md_spin_lock_irq(>device_lock);
> > > + unsigned long flags;
> > > + md_spin_lock_irqsave(>device_lock, flags);
> > > while (bh) {
> > > struct buffer_head *t = bh;
> > > bh=bh->b_next;
> > > @@ -103,7 +104,7 @@
> > > conf->freebh_cnt++;
> > > }
> > > }
> > > - md_spin_unlock_irq(>device_lock);
> > > + md_spin_unlock_irqrestore(>device_lock, flags);
> > > wake_up(>wait_buffer);
> > > }
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] deadlock fix
Yo All!
I see this patch did not make it into test11-pre1. Without it
raid1 and SMP do not work together. Please consider for test11-pre2.
RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
Here it is.
--- drivers/md/raid1.c.orgWed Oct 18 15:30:07 2000
+++ drivers/md/raid1.cWed Oct 18 15:33:08 2000
@@ -91,7 +91,8 @@
static inline void raid1_free_bh(raid1_conf_t *conf, struct buffer_head *bh)
{
- md_spin_lock_irq(conf-device_lock);
+ unsigned long flags;
+ md_spin_lock_irqsave(conf-device_lock, flags);
while (bh) {
struct buffer_head *t = bh;
bh=bh-b_next;
@@ -103,7 +104,7 @@
conf-freebh_cnt++;
}
}
- md_spin_unlock_irq(conf-device_lock);
+ md_spin_unlock_irqrestore(conf-device_lock, flags);
wake_up(conf-wait_buffer);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Any dual AGP slot motherboards?
Yo All! On Fri, 20 Oct 2000, J . A . Magallon wrote: > AFAIK, AGP is just a preferent PCI slot in the PCI bus; that is for you can > only have ONE AGP port on a PCI bus. No. The AGP bus is never ON a PCI bus. To quote the AGP 2.0 spec section 1.2: "A.G.P. neither replaces nor diminishes the necessity of PCI in the system. This high speed port (A.G.P.) is physically, logically, and electrically independent of the PCI bus." "The A.G.P. interface specification uses the 66 MHz PCI (PCI Local Bus Specification) specification as an operational baseline, and provides four significant performance extensions or enhancements to the PCI specification which are intended to optimize the A.G.P. for high performance 3D graphics applications. These A.G.P. extensions are not described in, or required by, the PCI Local Bus Specification. These extensions are: · Deeply pipelined memory read and write operations, fully hiding memory access latency. · Demultiplexing of address and data on the bus, allowing almost 100% bus efficiency. · New AC timing in the 3.3 V electrical specification that provides for one or two data transfers per 66-MHz clock cycle, allowing for real data throughput in excess of 500 MB/s. · A new low voltage electrical specification that allows four data transfers per 66-MHz clock cycle, providing real data throughput of up to 1 GB/s." So they started with the PCI spec, but they changed the logical meaning of a lot of the bus signals, they added a lot of bus signals, they run it about 8 times faster, they changed the voltage and a bunch of other stuff. I say it is a different animal now. > Please, could an expert point to the AGP standard defs ? http://developer.intel.com/technology/agp/ The spec itself is at: ftp://download.intel.com/technology/agp/downloads/agp20.pdf In any case, I do not see how this topic belongs on the l-k list. Contact me off-list if you need more info. RGDS GARY ----------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any dual AGP slot motherboards?
Yo James! On Fri, 20 Oct 2000, James Simmons wrote: > After much searching I couldn't find one. It was one of those mac rumors > people spread around. I still like to get more than one AGP going. If I > have multiple PCI bus in theory I should be able to have one AGP port on > each PCI bus. Right? AGP is much faster than PCI bus and has nothing to do with the PCI bus. So the number of multiple PCI buses has nothing to do with the number of AGP buses. The way to get multiple PCI buses is to bridge one PCI bus on to another. There are no changes required to the core chipset. There is no way (yet) to bridge one AGP bus on another. AGP is very tightly coupled with the main memory controller chip so it is unlikely that there will be any dual AGP motherboard until one of the big semi manufacturers puts that feature in a core chipset. RGDS GARY ------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any dual AGP slot motherboards?
Yo James! On Fri, 20 Oct 2000, James Simmons wrote: After much searching I couldn't find one. It was one of those mac rumors people spread around. I still like to get more than one AGP going. If I have multiple PCI bus in theory I should be able to have one AGP port on each PCI bus. Right? AGP is much faster than PCI bus and has nothing to do with the PCI bus. So the number of multiple PCI buses has nothing to do with the number of AGP buses. The way to get multiple PCI buses is to bridge one PCI bus on to another. There are no changes required to the core chipset. There is no way (yet) to bridge one AGP bus on another. AGP is very tightly coupled with the main memory controller chip so it is unlikely that there will be any dual AGP motherboard until one of the big semi manufacturers puts that feature in a core chipset. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any dual AGP slot motherboards?
Yo All! On Fri, 20 Oct 2000, J . A . Magallon wrote: AFAIK, AGP is just a preferent PCI slot in the PCI bus; that is for you can only have ONE AGP port on a PCI bus. No. The AGP bus is never ON a PCI bus. To quote the AGP 2.0 spec section 1.2: "A.G.P. neither replaces nor diminishes the necessity of PCI in the system. This high speed port (A.G.P.) is physically, logically, and electrically independent of the PCI bus." "The A.G.P. interface specification uses the 66 MHz PCI (PCI Local Bus Specification) specification as an operational baseline, and provides four significant performance extensions or enhancements to the PCI specification which are intended to optimize the A.G.P. for high performance 3D graphics applications. These A.G.P. extensions are not described in, or required by, the PCI Local Bus Specification. These extensions are: · Deeply pipelined memory read and write operations, fully hiding memory access latency. · Demultiplexing of address and data on the bus, allowing almost 100% bus efficiency. · New AC timing in the 3.3 V electrical specification that provides for one or two data transfers per 66-MHz clock cycle, allowing for real data throughput in excess of 500 MB/s. · A new low voltage electrical specification that allows four data transfers per 66-MHz clock cycle, providing real data throughput of up to 1 GB/s." So they started with the PCI spec, but they changed the logical meaning of a lot of the bus signals, they added a lot of bus signals, they run it about 8 times faster, they changed the voltage and a bunch of other stuff. I say it is a different animal now. Please, could an expert point to the AGP standard defs ? http://developer.intel.com/technology/agp/ The spec itself is at: ftp://download.intel.com/technology/agp/downloads/agp20.pdf In any case, I do not see how this topic belongs on the l-k list. Contact me off-list if you need more info. RGDS GARY ------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test10-pre3 Ooops
Yo All! Help! See below for my kernel oops. I have not been able to use any kernel after 2.4.0-test5 due to this problem. It happens shortly after booting the kernel and is very repeatable. This is a dual PII system with PIIX4 ide, 53c875 scsi and Raid 1. It is not a production system so I am open to any patches or tests. The system would not even stay up long enough to run ksymoops so I had to copy the data and run it under 2.2.17. Any ideas out there? RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 ksymoops 2.3.4 on i686 2.2.17pre10-RAID. Options used -V (default) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.0-test10 (specified) -m /usr/src/linux/System.map (default) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is ./modules a valid lsmod file? NMI Watchdog detected LOCKUP on CPU0, registers: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0082 eax: c01cb154 ebx: c122bdc0 ecx: edx: esi: c12b9d60 edi: 0282 ebp: 000e esp: c37fbe44 ds: 0018 es: 0018 ss: 0018 Process cc1 (pid: 1484, stackpage=c37fb000) Stack: c122bdc0 0401 000e c01df362 c010cab1 000e c12b9d60 c37fbea8 c036e6c0 c034b9c0 000e c37fbea0 c010cc98 000e c37fbea8 c122bdc0 c1384800 c1384c78 c122bdc0 c2722500 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f3 90 7e f5 e9 f7 8d f5 ff 80 3d 64 39 2f c0 00 f3 90 7e f5 >>EIP; c0272362<= Trace; c01df362 Trace; c010cab1 Trace; c010cc98 Trace; c010b370 Trace; c02215d3 Trace; c022167a Trace; c01927c9 Trace; c01c99a8 Trace; c01cdadb Trace; c01cb27e Trace; c01cda30 Trace; c010cab1 Trace; c010cc98 Trace; c010b370 Code; c0272362 <_EIP>: Code; c0272362<= 0: f3 90 repz nop<= Code; c0272364 2: 7e f5 jlefff9 <_EIP+0xfff9> c027235b Code; c0272366 4: e9 f7 8d f5 ffjmpfff58e00 <_EIP+0xfff58e00> c01cb162 Code; c027236b 9: 80 3d 64 39 2f c0 00 cmpb $0x0,0xc02f3964 Code; c0272372 10: f3 90 repz nop Code; c0272374 12: 7e f5 jle9 <_EIP+0x9> c027236b 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test10-pre3 Ooops
Yo All! Help! See below for my kernel oops. I have not been able to use any kernel after 2.4.0-test5 due to this problem. It happens shortly after booting the kernel and is very repeatable. This is a dual PII system with PIIX4 ide, 53c875 scsi and Raid 1. It is not a production system so I am open to any patches or tests. The system would not even stay up long enough to run ksymoops so I had to copy the data and run it under 2.2.17. Any ideas out there? RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 ksymoops 2.3.4 on i686 2.2.17pre10-RAID. Options used -V (default) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.0-test10 (specified) -m /usr/src/linux/System.map (default) No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is ./modules a valid lsmod file? NMI Watchdog detected LOCKUP on CPU0, registers: CPU:0 EIP:0010:[c0272362] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0082 eax: c01cb154 ebx: c122bdc0 ecx: edx: esi: c12b9d60 edi: 0282 ebp: 000e esp: c37fbe44 ds: 0018 es: 0018 ss: 0018 Process cc1 (pid: 1484, stackpage=c37fb000) Stack: c122bdc0 0401 000e c01df362 c010cab1 000e c12b9d60 c37fbea8 c036e6c0 c034b9c0 000e c37fbea0 c010cc98 000e c37fbea8 c122bdc0 c1384800 c1384c78 c122bdc0 c2722500 Call Trace: [c01df362] [c010cab1] [c010cc98] [c010b370] [c02215d3] [c022167a] [c01927c9] [c01c99a8] [c01cdadb] [c01cb27e] [c01cda30] [c010cab1] [c010cc98] [c010b370] Code: f3 90 7e f5 e9 f7 8d f5 ff 80 3d 64 39 2f c0 00 f3 90 7e f5 EIP; c0272362 stext_lock+4ba2/a820 = Trace; c01df362 scsi_dispatch_cmd+1c6/26c Trace; c010cab1 handle_IRQ_event+59/84 Trace; c010cc98 do_IRQ+a8/fc Trace; c010b370 ret_from_intr+0/20 Trace; c02215d3 raid1_end_bh_io+13b/148 Trace; c022167a raid1_end_request+9a/a4 Trace; c01927c9 end_that_request_first+65/c4 Trace; c01c99a8 ide_end_request+34/88 Trace; c01cdadb write_intr+ab/128 Trace; c01cb27e ide_intr+12a/194 Trace; c01cda30 write_intr+0/128 Trace; c010cab1 handle_IRQ_event+59/84 Trace; c010cc98 do_IRQ+a8/fc Trace; c010b370 ret_from_intr+0/20 Code; c0272362 stext_lock+4ba2/a820 _EIP: Code; c0272362 stext_lock+4ba2/a820 = 0: f3 90 repz nop= Code; c0272364 stext_lock+4ba4/a820 2: 7e f5 jlefff9 _EIP+0xfff9 c027235b stext_lock+4b9b/a820 Code; c0272366 stext_lock+4ba6/a820 4: e9 f7 8d f5 ffjmpfff58e00 _EIP+0xfff58e00 c01cb162 ide_intr+e/194 Code; c027236b stext_lock+4bab/a820 9: 80 3d 64 39 2f c0 00 cmpb $0x0,0xc02f3964 Code; c0272372 stext_lock+4bb2/a820 10: f3 90 repz nop Code; c0272374 stext_lock+4bb4/a820 12: 7e f5 jle9 _EIP+0x9 c027236b stext_lock+4bab/a820 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
