linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
linux-kernel@vger.kernel.org RE:For Your Urgent Perusal
Dear linux-kernel@vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.
Re: [PATCH v3] Bluetooth: automatically flushable packets aren't allowed on LE links
On Thu, Nov 20, 2014 at 10:51 AM, Steven Walter wrote: >> > I think Marcel was after just providing a clarifying code comment in >> > both places - having two branches of an if-statement doing exactly the >> > same thing looks a bit weird to me. To make thins completely clear I'd >> > suggest adding a simple helper function that you can call from both >> > places to get the needed flags, something like the following: >> >> I am actually fine with just adding a comment explaining the complex if >> statement on why it is correct. It is just a helper for everybody to >> understand what and why it is done that way. > > > Is the comment I added sufficient, or should I add one for the other if > condition as well? To me, the second condition is pretty straightforward: > if the caller requested it and the hardware supports it, use NO_FLUSH. The > relationship between FLUSH/NO_FLUSH and low-energy is much less clear and > more justifies a comment, in my opinion. Did a miss a reply to this? How would you like the next iteration of the patch to look? -- -Steven Walter -- 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 v3] Bluetooth: automatically flushable packets aren't allowed on LE links
On Thu, Nov 20, 2014 at 10:51 AM, Steven Walter stevenrwal...@gmail.com wrote: I think Marcel was after just providing a clarifying code comment in both places - having two branches of an if-statement doing exactly the same thing looks a bit weird to me. To make thins completely clear I'd suggest adding a simple helper function that you can call from both places to get the needed flags, something like the following: I am actually fine with just adding a comment explaining the complex if statement on why it is correct. It is just a helper for everybody to understand what and why it is done that way. Is the comment I added sufficient, or should I add one for the other if condition as well? To me, the second condition is pretty straightforward: if the caller requested it and the hardware supports it, use NO_FLUSH. The relationship between FLUSH/NO_FLUSH and low-energy is much less clear and more justifies a comment, in my opinion. Did a miss a reply to this? How would you like the next iteration of the patch to look? -- -Steven Walter stevenrwal...@gmail.com -- 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 v3] Bluetooth: automatically flushable packets aren't allowed on LE links
The bluetooth spec states that automatically flushable packets may not
be sent over a LE-U link.
Signed-off-by: Steven Walter
---
net/bluetooth/l2cap_core.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4af3821..7c4350f 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8
ident, u8 code, u16 len,
if (!skb)
return;
- if (lmp_no_flush_capable(conn->hcon->hdev))
+ if (lmp_no_flush_capable(conn->hcon->hdev) || conn->hcon->type ==
LE_LINK)
flags = ACL_START_NO_FLUSH;
else
flags = ACL_START;
@@ -784,7 +784,7 @@ static bool __chan_is_moving(struct l2cap_chan *chan)
static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb)
{
struct hci_conn *hcon = chan->conn->hcon;
- u16 flags;
+ u16 flags = ACL_START;
BT_DBG("chan %p, skb %p len %d priority %u", chan, skb, skb->len,
skb->priority);
@@ -798,11 +798,13 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct
sk_buff *skb)
return;
}
- if (!test_bit(FLAG_FLUSHABLE, >flags) &&
- lmp_no_flush_capable(hcon->hdev))
+ if (hcon->type == LE_LINK) {
+ /* LE-U does not support auto-flushing packets */
flags = ACL_START_NO_FLUSH;
- else
- flags = ACL_START;
+ } else if (!test_bit(FLAG_FLUSHABLE, >flags) &&
+ lmp_no_flush_capable(hcon->hdev)) {
+ flags = ACL_START_NO_FLUSH;
+ }
bt_cb(skb)->force_active = test_bit(FLAG_FORCE_ACTIVE, >flags);
hci_send_acl(chan->conn->hchan, skb, flags);
--
1.9.1
--
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 v2] l2cap_core: automatically flushable packets aren't allowed on LE links
The bluetooth spec states that automatically flushable packets may not be sent over a LE-U link. Signed-off-by: Steven Walter --- net/bluetooth/l2cap_core.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 4af3821..028fcc6 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, if (!skb) return; - if (lmp_no_flush_capable(conn->hcon->hdev)) + if (lmp_no_flush_capable(conn->hcon->hdev) || (conn->hcon->type == LE_LINK)) flags = ACL_START_NO_FLUSH; else flags = ACL_START; @@ -798,8 +798,9 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb) return; } - if (!test_bit(FLAG_FLUSHABLE, >flags) && - lmp_no_flush_capable(hcon->hdev)) + if ((hcon->type == LE_LINK) || + (!test_bit(FLAG_FLUSHABLE, >flags) && + lmp_no_flush_capable(hcon->hdev))) flags = ACL_START_NO_FLUSH; else flags = ACL_START; -- 1.9.1 -- 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 v2] l2cap_core: automatically flushable packets aren't allowed on LE links
The bluetooth spec states that automatically flushable packets may not be sent over a LE-U link. Signed-off-by: Steven Walter stevenrwal...@gmail.com --- net/bluetooth/l2cap_core.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 4af3821..028fcc6 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, if (!skb) return; - if (lmp_no_flush_capable(conn-hcon-hdev)) + if (lmp_no_flush_capable(conn-hcon-hdev) || (conn-hcon-type == LE_LINK)) flags = ACL_START_NO_FLUSH; else flags = ACL_START; @@ -798,8 +798,9 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb) return; } - if (!test_bit(FLAG_FLUSHABLE, chan-flags) - lmp_no_flush_capable(hcon-hdev)) + if ((hcon-type == LE_LINK) || + (!test_bit(FLAG_FLUSHABLE, chan-flags) + lmp_no_flush_capable(hcon-hdev))) flags = ACL_START_NO_FLUSH; else flags = ACL_START; -- 1.9.1 -- 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 v3] Bluetooth: automatically flushable packets aren't allowed on LE links
The bluetooth spec states that automatically flushable packets may not
be sent over a LE-U link.
Signed-off-by: Steven Walter stevenrwal...@gmail.com
---
net/bluetooth/l2cap_core.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4af3821..7c4350f 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8
ident, u8 code, u16 len,
if (!skb)
return;
- if (lmp_no_flush_capable(conn-hcon-hdev))
+ if (lmp_no_flush_capable(conn-hcon-hdev) || conn-hcon-type ==
LE_LINK)
flags = ACL_START_NO_FLUSH;
else
flags = ACL_START;
@@ -784,7 +784,7 @@ static bool __chan_is_moving(struct l2cap_chan *chan)
static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb)
{
struct hci_conn *hcon = chan-conn-hcon;
- u16 flags;
+ u16 flags = ACL_START;
BT_DBG(chan %p, skb %p len %d priority %u, chan, skb, skb-len,
skb-priority);
@@ -798,11 +798,13 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct
sk_buff *skb)
return;
}
- if (!test_bit(FLAG_FLUSHABLE, chan-flags)
- lmp_no_flush_capable(hcon-hdev))
+ if (hcon-type == LE_LINK) {
+ /* LE-U does not support auto-flushing packets */
flags = ACL_START_NO_FLUSH;
- else
- flags = ACL_START;
+ } else if (!test_bit(FLAG_FLUSHABLE, chan-flags)
+ lmp_no_flush_capable(hcon-hdev)) {
+ flags = ACL_START_NO_FLUSH;
+ }
bt_cb(skb)-force_active = test_bit(FLAG_FORCE_ACTIVE, chan-flags);
hci_send_acl(chan-conn-hchan, skb, flags);
--
1.9.1
--
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] l2cap_core: automatically flushable packets aren't supported by LE-only devices
The bluetooth spec states that automatically flushable packets may not be sent to a LE-only controller. The code already supports non-automatically-flushable packets, but uses a bit in the controller feature field to determine whether to use them. That bit is always zero for LE-only devices, so we need to check for the LE-only case explicitly. --- net/bluetooth/l2cap_core.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 4af3821..29d9b9c 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, if (!skb) return; - if (lmp_no_flush_capable(conn->hcon->hdev)) + if (lmp_no_flush_capable(conn->hcon->hdev) || !lmp_bredr_capable(conn->hcon->hdev)) flags = ACL_START_NO_FLUSH; else flags = ACL_START; @@ -798,8 +798,9 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb) return; } - if (!test_bit(FLAG_FLUSHABLE, >flags) && - lmp_no_flush_capable(hcon->hdev)) + if (!lmp_bredr_capable(hcon->hdev) || + (!test_bit(FLAG_FLUSHABLE, >flags) && + lmp_no_flush_capable(hcon->hdev))) flags = ACL_START_NO_FLUSH; else flags = ACL_START; -- 1.9.1 -- 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] l2cap_core: automatically flushable packets aren't supported by LE-only devices
The bluetooth spec states that automatically flushable packets may not be sent to a LE-only controller. The code already supports non-automatically-flushable packets, but uses a bit in the controller feature field to determine whether to use them. That bit is always zero for LE-only devices, so we need to check for the LE-only case explicitly. --- net/bluetooth/l2cap_core.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 4af3821..29d9b9c 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -764,7 +764,7 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len, if (!skb) return; - if (lmp_no_flush_capable(conn-hcon-hdev)) + if (lmp_no_flush_capable(conn-hcon-hdev) || !lmp_bredr_capable(conn-hcon-hdev)) flags = ACL_START_NO_FLUSH; else flags = ACL_START; @@ -798,8 +798,9 @@ static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb) return; } - if (!test_bit(FLAG_FLUSHABLE, chan-flags) - lmp_no_flush_capable(hcon-hdev)) + if (!lmp_bredr_capable(hcon-hdev) || + (!test_bit(FLAG_FLUSHABLE, chan-flags) + lmp_no_flush_capable(hcon-hdev))) flags = ACL_START_NO_FLUSH; else flags = ACL_START; -- 1.9.1 -- 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] V4L: Add additional ioctls to compat_ioctl32
With the addition of these ioctls, I'm able to watch TV with a 32-bit version of tvtime on x86_64 --- drivers/media/video/compat_ioctl32.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/compat_ioctl32.c b/drivers/media/video/compat_ioctl32.c index f065ad1..cefd138 100644 --- a/drivers/media/video/compat_ioctl32.c +++ b/drivers/media/video/compat_ioctl32.c @@ -848,6 +848,8 @@ long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg) case VIDIOCSFREQ32: case VIDIOCGAUDIO: case VIDIOCSAUDIO: + case VIDIOCGVBIFMT: + case VIDIOCSVBIFMT: #endif case VIDIOC_QUERYCAP: case VIDIOC_ENUM_FMT: @@ -874,7 +876,10 @@ long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg) case VIDIOC_ENUMINPUT: case VIDIOC_ENUMINPUT32: case VIDIOC_G_CTRL: + case VIDIOC_S_CTRL: case VIDIOC_S_CTRL32: + case VIDIOC_S_FREQUENCY: + case VIDIOC_G_FREQUENCY: case VIDIOC_QUERYCTRL: case VIDIOC_G_INPUT32: case VIDIOC_S_INPUT32: -- 1.5.3.rc2 -- -Steven Walter <[EMAIL PROTECTED]> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." -Robert Heinlein - 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] V4L: Add additional ioctls to compat_ioctl32
With the addition of these ioctls, I'm able to watch TV with a 32-bit version of tvtime on x86_64 --- drivers/media/video/compat_ioctl32.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/compat_ioctl32.c b/drivers/media/video/compat_ioctl32.c index f065ad1..cefd138 100644 --- a/drivers/media/video/compat_ioctl32.c +++ b/drivers/media/video/compat_ioctl32.c @@ -848,6 +848,8 @@ long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg) case VIDIOCSFREQ32: case VIDIOCGAUDIO: case VIDIOCSAUDIO: + case VIDIOCGVBIFMT: + case VIDIOCSVBIFMT: #endif case VIDIOC_QUERYCAP: case VIDIOC_ENUM_FMT: @@ -874,7 +876,10 @@ long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg) case VIDIOC_ENUMINPUT: case VIDIOC_ENUMINPUT32: case VIDIOC_G_CTRL: + case VIDIOC_S_CTRL: case VIDIOC_S_CTRL32: + case VIDIOC_S_FREQUENCY: + case VIDIOC_G_FREQUENCY: case VIDIOC_QUERYCTRL: case VIDIOC_G_INPUT32: case VIDIOC_S_INPUT32: -- 1.5.3.rc2 -- -Steven Walter [EMAIL PROTECTED] A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Robert Heinlein - 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] saa7134: add support for the Encore ENL-TV
This patch adds a board definition for the Encore ENL-TV card, and
adds its PCI subdevice to the ID table. Patch is output from
git-format-patch against Linus' git tree.
Please let me know if there are any deficiencies in this submission.
--
-Steven Walter <[EMAIL PROTECTED]>
From c976999abbe1393dfa511a43cab145c17103bbdf Mon Sep 17 00:00:00 2001
From: Steven Walter <[EMAIL PROTECTED]>
Date: Tue, 5 Dec 2006 23:41:55 -0500
Subject: [PATCH] [PATCH] Add support for the Encore ENL-TV to saa7134
Create a board definition for the ENL-TV, and add its subdevice ID to the
table.
Signed-off-by: Steven Walter <[EMAIL PROTECTED]>
---
drivers/media/video/saa7134/saa7134-cards.c | 24
drivers/media/video/saa7134/saa7134.h |1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 51f0cfd..dd3758a 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -3022,6 +3022,24 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1,
},
},
+ [SAA7134_BOARD_ENCORE_ENLTV] = {
+ /* Steven Walter <[EMAIL PROTECTED]> */
+ .name = "Encore ENLTV",
+ .tuner_type = TUNER_TNF_5335MF,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = LINE2,
+ .tv = 1,
+ },{
+ .name = name_svideo,
+ .vmux = 6,
+ .amux = LINE1,
+ }},
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -3631,6 +3649,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0x4860,
.driver_data = SAA7134_BOARD_ASUS_EUROPA2_HYBRID,
},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+ .subvendor= PCI_VENDOR_ID_PHILIPS,
+ .subdevice= 0x2342,
+ .driver_data = SAA7134_BOARD_ENCORE_ENLTV,
+ },{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff --git a/drivers/media/video/saa7134/saa7134.h
b/drivers/media/video/saa7134/saa7134.h
index 7cf96b4..8ee165a 100644
--- a/drivers/media/video/saa7134/saa7134.h
+++ b/drivers/media/video/saa7134/saa7134.h
@@ -227,6 +227,7 @@ #define SAA7134_BOARD_FLYDVBS_LR300 97
#define SAA7134_BOARD_PROTEUS_2309 98
#define SAA7134_BOARD_AVERMEDIA_A16AR 99
#define SAA7134_BOARD_ASUS_EUROPA2_HYBRID 100
+#define SAA7134_BOARD_ENCORE_ENLTV 101
#define SAA7134_MAXBOARDS 8
#define SAA7134_INPUT_MAX 8
--
1.4.1
[PATCH] saa7134: add support for the Encore ENL-TV
This patch adds a board definition for the Encore ENL-TV card, and
adds its PCI subdevice to the ID table. Patch is output from
git-format-patch against Linus' git tree.
Please let me know if there are any deficiencies in this submission.
--
-Steven Walter [EMAIL PROTECTED]
From c976999abbe1393dfa511a43cab145c17103bbdf Mon Sep 17 00:00:00 2001
From: Steven Walter [EMAIL PROTECTED]
Date: Tue, 5 Dec 2006 23:41:55 -0500
Subject: [PATCH] [PATCH] Add support for the Encore ENL-TV to saa7134
Create a board definition for the ENL-TV, and add its subdevice ID to the
table.
Signed-off-by: Steven Walter [EMAIL PROTECTED]
---
drivers/media/video/saa7134/saa7134-cards.c | 24
drivers/media/video/saa7134/saa7134.h |1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 51f0cfd..dd3758a 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -3022,6 +3022,24 @@ struct saa7134_board saa7134_boards[] =
.amux = LINE1,
},
},
+ [SAA7134_BOARD_ENCORE_ENLTV] = {
+ /* Steven Walter [EMAIL PROTECTED] */
+ .name = Encore ENLTV,
+ .tuner_type = TUNER_TNF_5335MF,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = LINE2,
+ .tv = 1,
+ },{
+ .name = name_svideo,
+ .vmux = 6,
+ .amux = LINE1,
+ }},
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -3631,6 +3649,12 @@ struct pci_device_id saa7134_pci_tbl[] =
.subdevice= 0x4860,
.driver_data = SAA7134_BOARD_ASUS_EUROPA2_HYBRID,
},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+ .subvendor= PCI_VENDOR_ID_PHILIPS,
+ .subdevice= 0x2342,
+ .driver_data = SAA7134_BOARD_ENCORE_ENLTV,
+ },{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff --git a/drivers/media/video/saa7134/saa7134.h
b/drivers/media/video/saa7134/saa7134.h
index 7cf96b4..8ee165a 100644
--- a/drivers/media/video/saa7134/saa7134.h
+++ b/drivers/media/video/saa7134/saa7134.h
@@ -227,6 +227,7 @@ #define SAA7134_BOARD_FLYDVBS_LR300 97
#define SAA7134_BOARD_PROTEUS_2309 98
#define SAA7134_BOARD_AVERMEDIA_A16AR 99
#define SAA7134_BOARD_ASUS_EUROPA2_HYBRID 100
+#define SAA7134_BOARD_ENCORE_ENLTV 101
#define SAA7134_MAXBOARDS 8
#define SAA7134_INPUT_MAX 8
--
1.4.1
Re: Tyan Thunder K7 & 2 1.2Ghz Athlon MPs
On Thu, Jul 19, 2001 at 03:24:09PM -0400, Ryan C. Bonham wrote: > I get the following messages, I will paste dmesg.log at the bottom if you > want to see it.. > mtrr: your CPUs had inconsistent fixed MTRR settings > mtrr: probably your BIOS does not setup all CPUs > >From what i gather that message can just be ignored, it stems from bios > vendors not following specs, and Linux is just making corrections.. Am I > right? The bios really isn't doing anything wrong, more like its not doing anything. It probably just isn't setting the second CPU. Linux, as far as I know, will set up the second CPU for you, and it only letting you know what's going on. > agpgart: Maximum main memory to use for agp memory: 816M > agpgart: Unsupported AMD chipset (device id: 700c), you might want to try > agp_try_unsupported=1. > agpgart: no supported devices found. > > Ok, I understand the AMD chipset on this board is new, my question here is, > how do I turn on agp_try_unsupported.. Patch the kernel? Even easier; agp_try_unsupported is a kernel command line parameter. If you're using LILO, boot with the line "linux agp_try_unsupported=1" or the like, or put "append="agp_try_unsupported=1"" in your lilo.conf file. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: Tyan Thunder K7 2 1.2Ghz Athlon MPs
On Thu, Jul 19, 2001 at 03:24:09PM -0400, Ryan C. Bonham wrote: I get the following messages, I will paste dmesg.log at the bottom if you want to see it.. mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: probably your BIOS does not setup all CPUs From what i gather that message can just be ignored, it stems from bios vendors not following specs, and Linux is just making corrections.. Am I right? The bios really isn't doing anything wrong, more like its not doing anything. It probably just isn't setting the second CPU. Linux, as far as I know, will set up the second CPU for you, and it only letting you know what's going on. agpgart: Maximum main memory to use for agp memory: 816M agpgart: Unsupported AMD chipset (device id: 700c), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. Ok, I understand the AMD chipset on this board is new, my question here is, how do I turn on agp_try_unsupported.. Patch the kernel? Even easier; agp_try_unsupported is a kernel command line parameter. If you're using LILO, boot with the line linux agp_try_unsupported=1 or the like, or put append=agp_try_unsupported=1 in your lilo.conf file. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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/
VIA Southbridge bug (Was: Crash on boot (2.4.5))
Great, glad to here it. Who (if anyone) is still attempting to unravel the puzzle of the Via southbridge bug? You, Andy, should try and get in touch with them and help debug this thing, if you're up to it. On Mon, Jun 25, 2001 at 01:17:57AM -0500, Andy Ward wrote: > Well, I have tried your suggestion, and it works beautifully... The > only change I made was to the cpu type (to 686), and everything *just* > works now... Thanks, all!!! > > > From the look of things, you're being bitten by the VIA southbridge > > problem. As I've gathered, its some sort of interaction with that chip > > and the 3DNow! fast copy routines the kernel uses. > > > > If you compile the kernel for a 686, does the problem go away? What > > about 586 or lower? If so, I believe there are some people working on > > finding common aspects of the hardware that experience this problem, > > though I don't remember who. You should get in contact with them, or > > they might get into contact with you. > > > > Good luck on working this out. > > -- > > -Steven > > In a time of universal deceit, telling the truth is a revolutionary act. > > -- George Orwell -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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/
VIA Southbridge bug (Was: Crash on boot (2.4.5))
Great, glad to here it. Who (if anyone) is still attempting to unravel the puzzle of the Via southbridge bug? You, Andy, should try and get in touch with them and help debug this thing, if you're up to it. On Mon, Jun 25, 2001 at 01:17:57AM -0500, Andy Ward wrote: Well, I have tried your suggestion, and it works beautifully... The only change I made was to the cpu type (to 686), and everything *just* works now... Thanks, all!!! From the look of things, you're being bitten by the VIA southbridge problem. As I've gathered, its some sort of interaction with that chip and the 3DNow! fast copy routines the kernel uses. If you compile the kernel for a 686, does the problem go away? What about 586 or lower? If so, I believe there are some people working on finding common aspects of the hardware that experience this problem, though I don't remember who. You should get in contact with them, or they might get into contact with you. Good luck on working this out. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: Alan Cox quote? (was: Re: accounting for threads)
On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote: > Take a programmer comming from other system to linux. If he wants multi- > threading and protable code, he will choose pthreads. And you say to him: > do it with 'clone', it is better. Answer: non protable. Again: do it > with fork(), it is fast in linux. Answer: better for linux, but it is a > real pain in other systems. > > And worst, you are allowing people to program based on a tool that will give > VERY diferent performance when ported to other systems. They use fork(). > They port their app to solaris. The performance sucks. It is not Solaris > fault. It is linux fast fork() that makes people not looking for the > correct standard tool for what they want todo. This sounds to my like "Linux is making other OSes look bad. Cut it out." -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: Crash on boot (2.4.5)
On Sun, Jun 24, 2001 at 01:51:09PM -0500, Daniel Fraley wrote: > Hi, everyone.. I'm borrowing my roommate's email, so please send replies to > [EMAIL PROTECTED] Thanks! > > Here's my problem... when I boot anything 2.4, I get several oopsen in a > row, all of which are either (most commonly) kernel paging request could not > be handled, or (much less common) unable to handle kernel Null pointer > dereference. I will send any info on request, but here's my hardware and > kernel config: > > iWill KKR-266R (Via 8363 Northbridge, 686B south) > AMD tbird 1GHz > 256MB cas2 pc133 sdram > ATI Radeon DDR 64MB VIVO > Kingston KNE120TX (Realtek 8139 chip) > SBLive! 5.1 > IBM GXP75 30GB (on the via ide controller) > Pioneer 16x dvd > ls120 > > This happens regardless if I turn on swap or not. When swap is on, it is a > 128MB partition (and yes, I'm aware of the recommendation of 2x RAM, but I > believe I read somewhere that someone was working on that, and I didn't want > to waste the extra 384MB on swap). > > Is there anything I can do to fix this? > > -- andyw > > p.s., booting with devfs=nomount is better, but still causes oopsen (I get > to a login prompt, but if I do much more than mount a disk a copy to it, the > system freaks) >From the look of things, you're being bitten by the VIA southbridge problem. As I've gathered, its some sort of interaction with that chip and the 3DNow! fast copy routines the kernel uses. If you compile the kernel for a 686, does the problem go away? What about 586 or lower? If so, I believe there are some people working on finding common aspects of the hardware that experience this problem, though I don't remember who. You should get in contact with them, or they might get into contact with you. Good luck on working this out. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.[5 - 6pre5] boomerang_start_xmit -> kernel panic
I too have been experiencing this on a gateway for a DSL modem. The backtrace is almost exactly the same. On this machine, the bug results in an "Aieee: Killing Interrupt Handler". I have to manually copy the oops, and as such I copied only the backtrace, and parts of it may be incorrect. I've attached it anyway, just in case it helps someone. I would really like to see this fixed, and so am willing to help diagnose and test any patches. On Sun, Jun 24, 2001 at 10:34:51AM +0200, Matthias Papesch wrote: > Hi, > > I've been repeatedly experiencing the same kernel panic. It happens on a > computer that acts as an isdn internet gateway for my home network. Two other > computers, that have the same kernel and NICs but don't do ip-forwarding have > not crashed so far. > > * NIC: 3com 3c905B-TX (PCI) > * ISDN: Teles 16.3 (ISA) > > The calling stack always looked pretty much the same (see Attachment). > The panic occurs, when multiple internet connections are in use. > > > Regards, > Matthias > > PS: Please put into CC, as I am not subscribed to the list. > I've skimmed over the last two weeks of the archive, but did not find > anything that looked similar to me. > > -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell ksymoops 2.3.4 on i586 2.4.5-ac2. Options used -V (default) -K (specified) -L (specified) -O (specified) -m System.map-2.4.5 (specified) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c01aa00b Trace; c01aabb3 <__pskb_pull_tail+2f/2d4> Trace; c01ad416 Trace; c01b0453 Trace; c01b8bcd Trace; c01b1317 Trace; c01b633c Trace; c01b8b32 Trace; c01b8b4c Trace; c01638a0 Trace; c01b1317 Trace; c01b62ed Trace; c01b633c Trace; c01b55d8 Trace; c01b524f Trace; c01b55d8 Trace; c01b1317 Trace; c01b5435 Trace; c01b55d8 Trace; c01ad9ab Trace; c0116190 Trace; c0107ef2 Trace; c0106b20 1 warning issued. Results may not be reliable.
Re: 2.4.[5 - 6pre5] boomerang_start_xmit - kernel panic
I too have been experiencing this on a gateway for a DSL modem. The backtrace is almost exactly the same. On this machine, the bug results in an Aieee: Killing Interrupt Handler. I have to manually copy the oops, and as such I copied only the backtrace, and parts of it may be incorrect. I've attached it anyway, just in case it helps someone. I would really like to see this fixed, and so am willing to help diagnose and test any patches. On Sun, Jun 24, 2001 at 10:34:51AM +0200, Matthias Papesch wrote: Hi, I've been repeatedly experiencing the same kernel panic. It happens on a computer that acts as an isdn internet gateway for my home network. Two other computers, that have the same kernel and NICs but don't do ip-forwarding have not crashed so far. * NIC: 3com 3c905B-TX (PCI) * ISDN: Teles 16.3 (ISA) The calling stack always looked pretty much the same (see Attachment). The panic occurs, when multiple internet connections are in use. Regards, Matthias PS: Please put into CC, as I am not subscribed to the list. I've skimmed over the last two weeks of the archive, but did not find anything that looked similar to me. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell ksymoops 2.3.4 on i586 2.4.5-ac2. Options used -V (default) -K (specified) -L (specified) -O (specified) -m System.map-2.4.5 (specified) Call Trace: [c01aa00b] [c01aabb3] [c01ad416] [c01b0453] [c01b8bcd] [c01b1317] [c01b633c] [c01b8b32] [c01b8b4c] [c01638a0] [c01b1317] [c01b62ed] [c01b633c] [c01b55d8] [c01b524f] [c01b55d8] [c01b1317] [c01b5435] [c01b55d8] [c01ad9ab] [c0116190] [c0107ef2] [c0106b20] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c01aa00b skb_release_data+5f/70 Trace; c01aabb3 __pskb_pull_tail+2f/2d4 Trace; c01ad416 dev_queue_xmit+26/1e4 Trace; c01b0453 neigh_resolve_output+113/184 Trace; c01b8bcd ip_finish_output2+81/b4 Trace; c01b1317 nf_hook_slow+e3/124 Trace; c01b633c ip_forward_finish+0/54 Trace; c01b8b32 ip_finish_output+e2/e8 Trace; c01b8b4c ip_finish_output2+0/b4 Trace; c01638a0 nfsd_write+88/29c Trace; c01b1317 nf_hook_slow+e3/124 Trace; c01b62ed ip_forward+19d/1ec Trace; c01b633c ip_forward_finish+0/54 Trace; c01b55d8 ip_rcv_finish+0/1a8 Trace; c01b524f ip_rcv+13f/35c Trace; c01b55d8 ip_rcv_finish+0/1a8 Trace; c01b1317 nf_hook_slow+e3/124 Trace; c01b5435 ip_rcv+325/35c Trace; c01b55d8 ip_rcv_finish+0/1a8 Trace; c01ad9ab net_rx_action+13b/218 Trace; c0116190 do_softirq+40/64 Trace; c0107ef2 do_IRQ+a2/b0 Trace; c0106b20 ret_from_intr+0/20 1 warning issued. Results may not be reliable.
Re: Crash on boot (2.4.5)
On Sun, Jun 24, 2001 at 01:51:09PM -0500, Daniel Fraley wrote: Hi, everyone.. I'm borrowing my roommate's email, so please send replies to [EMAIL PROTECTED] Thanks! Here's my problem... when I boot anything 2.4, I get several oopsen in a row, all of which are either (most commonly) kernel paging request could not be handled, or (much less common) unable to handle kernel Null pointer dereference. I will send any info on request, but here's my hardware and kernel config: iWill KKR-266R (Via 8363 Northbridge, 686B south) AMD tbird 1GHz 256MB cas2 pc133 sdram ATI Radeon DDR 64MB VIVO Kingston KNE120TX (Realtek 8139 chip) SBLive! 5.1 IBM GXP75 30GB (on the via ide controller) Pioneer 16x dvd ls120 This happens regardless if I turn on swap or not. When swap is on, it is a 128MB partition (and yes, I'm aware of the recommendation of 2x RAM, but I believe I read somewhere that someone was working on that, and I didn't want to waste the extra 384MB on swap). Is there anything I can do to fix this? -- andyw p.s., booting with devfs=nomount is better, but still causes oopsen (I get to a login prompt, but if I do much more than mount a disk a copy to it, the system freaks) From the look of things, you're being bitten by the VIA southbridge problem. As I've gathered, its some sort of interaction with that chip and the 3DNow! fast copy routines the kernel uses. If you compile the kernel for a 686, does the problem go away? What about 586 or lower? If so, I believe there are some people working on finding common aspects of the hardware that experience this problem, though I don't remember who. You should get in contact with them, or they might get into contact with you. Good luck on working this out. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: Alan Cox quote? (was: Re: accounting for threads)
On Mon, Jun 25, 2001 at 12:30:02AM +0200, J . A . Magallon wrote: Take a programmer comming from other system to linux. If he wants multi- threading and protable code, he will choose pthreads. And you say to him: do it with 'clone', it is better. Answer: non protable. Again: do it with fork(), it is fast in linux. Answer: better for linux, but it is a real pain in other systems. And worst, you are allowing people to program based on a tool that will give VERY diferent performance when ported to other systems. They use fork(). They port their app to solaris. The performance sucks. It is not Solaris fault. It is linux fast fork() that makes people not looking for the correct standard tool for what they want todo. This sounds to my like Linux is making other OSes look bad. Cut it out. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:55:10PM -0400, Tom Diehl wrote: > What is the best way to install the modules? Is there a directory _all_ of > the modules exist in b4 you do "make modules_install". I usually end up > setting EXTRAVERSION to something unique and doing a make modules_install. > That way it does not hose up the modules for the build machine. > Is there a better way? Not anymore there isn't. You'll just have to run make modules_install as 'INSTALL_MOD_DIR="/path/to/module" make modules_install' -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:55:10PM -0400, Tom Diehl wrote: What is the best way to install the modules? Is there a directory _all_ of the modules exist in b4 you do make modules_install. I usually end up setting EXTRAVERSION to something unique and doing a make modules_install. That way it does not hose up the modules for the build machine. Is there a better way? Not anymore there isn't. You'll just have to run make modules_install as 'INSTALL_MOD_DIR=/path/to/module make modules_install' -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: Error in documentation?
It does appear that the documentation regarding this is out of date. However, you can still install modules to a given location by: INSTALL_MOD_PATH="/path/to/modules" make modules_install Had to dig through the Makefile for that, though it may actually be documented somewhere. On Mon, Jun 18, 2001 at 11:15:11AM -0400, Geoffrey Gallaway wrote: > linux/Documentation/modules.txt says that I should find my modules in > "linux/modules" after running "make modules". However, this is > apparently not true as I see no modules directory. > > I am trying to compile a kernel with lots of modules for a machine > without a network connection. To move the kernel, I simply copy it to > floppy and move it over to the other machine. However, for the modules, > is my only choice appears to be "make modules-install" then tar up > /lib/modules/kernel-release/ and then remove the directory. Is there a > cleaner way to handle this? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: Error in documentation?
It does appear that the documentation regarding this is out of date. However, you can still install modules to a given location by: INSTALL_MOD_PATH=/path/to/modules make modules_install Had to dig through the Makefile for that, though it may actually be documented somewhere. On Mon, Jun 18, 2001 at 11:15:11AM -0400, Geoffrey Gallaway wrote: linux/Documentation/modules.txt says that I should find my modules in linux/modules after running make modules. However, this is apparently not true as I see no modules directory. I am trying to compile a kernel with lots of modules for a machine without a network connection. To move the kernel, I simply copy it to floppy and move it over to the other machine. However, for the modules, is my only choice appears to be make modules-install then tar up /lib/modules/kernel-release/ and then remove the directory. Is there a cleaner way to handle this? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: a memory-related problem?
Probably what happens is that your BIOS stores some data in the top megabyte of RAM, but doesn't set up the memory map to reflect this. Therefore, Linux overwrites whatevers up there, causing problems. On Sun, Jun 17, 2001 at 09:26:50PM +0200, Ronald Bultje wrote: > P6b has three mem-slots. I would get "unresolved errors in init" if I > had 2x64+1x128 sticks, and I would get oopses if I had 2x128M sticks. So > there is indeed a weird difference. > I just noticed this: if I supply "linux-2.4.4 mem=255M" instead of > "linux-2.4.4 mem=256M" at the lilo prompt, it does work. Is this a bug > in the code that handles options given at startup-time? (I only tried > this for 2x128 sticks but I suppose this is the same for 2x64+1x128 > sticks - I guess I'm too lazy to try it out). -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: a memory-related problem?
Probably what happens is that your BIOS stores some data in the top megabyte of RAM, but doesn't set up the memory map to reflect this. Therefore, Linux overwrites whatevers up there, causing problems. On Sun, Jun 17, 2001 at 09:26:50PM +0200, Ronald Bultje wrote: P6b has three mem-slots. I would get unresolved errors in init if I had 2x64+1x128 sticks, and I would get oopses if I had 2x128M sticks. So there is indeed a weird difference. I just noticed this: if I supply linux-2.4.4 mem=255M instead of linux-2.4.4 mem=256M at the lilo prompt, it does work. Is this a bug in the code that handles options given at startup-time? (I only tried this for 2x128 sticks but I suppose this is the same for 2x64+1x128 sticks - I guess I'm too lazy to try it out). -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: [PATCH] fix warning in tdfxfb.c
On Sat, Jun 16, 2001 at 02:59:34PM -0500, Josh Myer wrote: > It might be better to add a default case to the switch statement below, so > this symbol doesn't just eat up another 4(8 on some platforms, and i'm > sure others) bytes of memory unneccesarily. I'm not quite sure I follow you. The default case should never be reached, because only the three cases currently present are allowed by the encapsulating 'if' statement. Even so, how would adding a default case get rid of the variable or save space some other way? > anyway, it doesn't really matter. i'd test my hypothesis, but i've got > people coming over this afternoon =) the driver looks like it might use > some scrubbing anyway (s!//(.*)$!/\* $1 \*/!...) Good point. Perhaps I'll prepare a larger patch with this and other cleanups. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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] fix warning in tdfxfb.c
This patch is obviously correct. It doesn't appear that tdfxfb has a
maintainer, so I'm sending this patch to the list. Nothing
earth-shattering, it just removes a warning during build.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- tdfxfb.c~ Sat Jun 16 13:09:08 2001
+++ tdfxfb.cSat Jun 16 13:09:21 2001
@@ -1892,7 +1892,7 @@
((pdev->device == PCI_DEVICE_ID_3DFX_BANSHEE) ||
(pdev->device == PCI_DEVICE_ID_3DFX_VOODOO3) ||
(pdev->device == PCI_DEVICE_ID_3DFX_VOODOO5))) {
- char *name;
+ char *name = NULL;
fb_info.dev = pdev->device;
switch (pdev->device) {
-
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] fix warning in tdfxfb.c
This patch is obviously correct. It doesn't appear that tdfxfb has a
maintainer, so I'm sending this patch to the list. Nothing
earth-shattering, it just removes a warning during build.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- tdfxfb.c~ Sat Jun 16 13:09:08 2001
+++ tdfxfb.cSat Jun 16 13:09:21 2001
@@ -1892,7 +1892,7 @@
((pdev-device == PCI_DEVICE_ID_3DFX_BANSHEE) ||
(pdev-device == PCI_DEVICE_ID_3DFX_VOODOO3) ||
(pdev-device == PCI_DEVICE_ID_3DFX_VOODOO5))) {
- char *name;
+ char *name = NULL;
fb_info.dev = pdev-device;
switch (pdev-device) {
-
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: [PATCH] fix warning in tdfxfb.c
On Sat, Jun 16, 2001 at 02:59:34PM -0500, Josh Myer wrote: It might be better to add a default case to the switch statement below, so this symbol doesn't just eat up another 4(8 on some platforms, and i'm sure others) bytes of memory unneccesarily. I'm not quite sure I follow you. The default case should never be reached, because only the three cases currently present are allowed by the encapsulating 'if' statement. Even so, how would adding a default case get rid of the variable or save space some other way? anyway, it doesn't really matter. i'd test my hypothesis, but i've got people coming over this afternoon =) the driver looks like it might use some scrubbing anyway (s!//(.*)$!/\* $1 \*/!...) Good point. Perhaps I'll prepare a larger patch with this and other cleanups. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: PPP: VJ uncompressed error
What kernel are you using?? I used to get it after I switced from a Linux-supported winmodem to a hardware modem, but the messages are now mysteriously absent from me logs. If you're running something prior to 2.4.5, I'd say it was fixed there. Also, it could've been fixed in Alan's tree; I'm running 2.4.5-ac2 On Thu, Jun 14, 2001 at 03:55:21PM +0200, Jacek Pop?awski wrote: > I see this message few times daily: > > PPP: VJ uncompressed error > > What does it mean? I searched news archives, HOWTOs, WWW, but only place I found that > string is kernel source. > > - > 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/ -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: PPP: VJ uncompressed error
What kernel are you using?? I used to get it after I switced from a Linux-supported winmodem to a hardware modem, but the messages are now mysteriously absent from me logs. If you're running something prior to 2.4.5, I'd say it was fixed there. Also, it could've been fixed in Alan's tree; I'm running 2.4.5-ac2 On Thu, Jun 14, 2001 at 03:55:21PM +0200, Jacek Pop?awski wrote: I see this message few times daily: PPP: VJ uncompressed error What does it mean? I searched news archives, HOWTOs, WWW, but only place I found that string is kernel source. - 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/ -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: ftape and kernel 2.4 problem
Here's a patch I wrote to allow ftape to compile against 2.4.something.
It still works with 2.4.5. I'm not sure if it works entirely (it seems
to), but it compiles and seems to work. Enjoy!
On Thu, Jun 07, 2001 at 05:12:31PM +0200, Friedrich Lobenstock wrote:
> Hi!
>
> As the linux-ftape mailing list is gone I'm asking you guys.
>
> Can someone tell me how to adapt the ftape driver that I can use it
> under kernel 2.4.x (x >= 5)? I'm not that into kernel hacking that
> I know what changed from 2.2.x to 2.4.x. Below is the output of make.
>
> BTW why wasn't the newer ftape driver ported to 2.4 but the stone age
> ftape driver is still in 2.4?
>
> PS: Please CC me because I'm not on linux-kernel.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
diff -ru ftape-4.04a/ftape/lowlevel/ftape-init.h
ftape-4.04a.mod/ftape/lowlevel/ftape-init.h
--- ftape-4.04a/ftape/lowlevel/ftape-init.h Mon Jul 3 05:13:06 2000
+++ ftape-4.04a.mod/ftape/lowlevel/ftape-init.h Mon Feb 5 18:58:42 2001
@@ -67,7 +67,7 @@
}
extern inline int ft_sigtest(unsigned long mask)
{
- return (current->signal.sig[0] & mask);
+ return (current->sigpending & mask);
}
extern inline int ft_killed(void)
{
diff -ru ftape-4.04a/include/linux/ftape.h ftape-4.04a.mod/include/linux/ftape.h
--- ftape-4.04a/include/linux/ftape.h Tue Jul 25 06:04:47 2000
+++ ftape-4.04a.mod/include/linux/ftape.h Mon Feb 5 18:59:35 2001
@@ -28,7 +28,7 @@
* for the QIC-40/80/3010/3020 floppy-tape driver for Linux.
*
*/
-
+#define __initlocaldata __initdata
#define FTAPE_VERSION "ftape v4.04a 07/25/2000"
#ifdef __KERNEL__
Re: ftape and kernel 2.4 problem
Here's a patch I wrote to allow ftape to compile against 2.4.something.
It still works with 2.4.5. I'm not sure if it works entirely (it seems
to), but it compiles and seems to work. Enjoy!
On Thu, Jun 07, 2001 at 05:12:31PM +0200, Friedrich Lobenstock wrote:
Hi!
As the linux-ftape mailing list is gone I'm asking you guys.
Can someone tell me how to adapt the ftape driver that I can use it
under kernel 2.4.x (x = 5)? I'm not that into kernel hacking that
I know what changed from 2.2.x to 2.4.x. Below is the output of make.
BTW why wasn't the newer ftape driver ported to 2.4 but the stone age
ftape driver is still in 2.4?
PS: Please CC me because I'm not on linux-kernel.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
diff -ru ftape-4.04a/ftape/lowlevel/ftape-init.h
ftape-4.04a.mod/ftape/lowlevel/ftape-init.h
--- ftape-4.04a/ftape/lowlevel/ftape-init.h Mon Jul 3 05:13:06 2000
+++ ftape-4.04a.mod/ftape/lowlevel/ftape-init.h Mon Feb 5 18:58:42 2001
@@ -67,7 +67,7 @@
}
extern inline int ft_sigtest(unsigned long mask)
{
- return (current-signal.sig[0] mask);
+ return (current-sigpending mask);
}
extern inline int ft_killed(void)
{
diff -ru ftape-4.04a/include/linux/ftape.h ftape-4.04a.mod/include/linux/ftape.h
--- ftape-4.04a/include/linux/ftape.h Tue Jul 25 06:04:47 2000
+++ ftape-4.04a.mod/include/linux/ftape.h Mon Feb 5 18:59:35 2001
@@ -28,7 +28,7 @@
* for the QIC-40/80/3010/3020 floppy-tape driver for Linux.
*
*/
-
+#define __initlocaldata __initdata
#define FTAPE_VERSION ftape v4.04a 07/25/2000
#ifdef __KERNEL__
[OOPS] in locks_remove_posix
Just got this oops in 2.4.5-ac2. Can't reproduce it as of yet; if I find a way, I'll give notice. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell ksymoops 2.3.4 on i586 2.4.5-ac2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac2/ (default) -m /boot/System.map-2.4.5-ac2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __io_virt_debug_R__ver___io_virt_debug not found in System.map. Ignoring ksyms_base entry Unable to handle kernel paging request at virtual address ff14 c013ae26 *pde = 1063 Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: ff0c ebx: c66317e0 ecx: edx: c66317e0 esi: edi: ebp: b5b8 esp: c1a9ff90 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 227, stackpage=c1a9f000) Stack: c012ad38 c66317e0 c1930200 c66317e0 c66317e0 080ed570 c012ad87 c66317e0 c1930200 c1a9e000 c0106aa3 0005 4000 080ed570 b5b8 0006 002b 002b 0006 0809a982 Call Trace: [] [] [] Code: 8b 40 08 8b 40 08 8b 74 24 10 8b 90 a0 00 00 00 85 d2 74 4e >>EIP; c013ae26<= Trace; c012ad38 Trace; c012ad87 Trace; c0106aa3 Code; c013ae26 <_EIP>: Code; c013ae26<= 0: 8b 40 08 mov0x8(%eax),%eax <= Code; c013ae29 3: 8b 40 08 mov0x8(%eax),%eax Code; c013ae2c 6: 8b 74 24 10 mov0x10(%esp,1),%esi Code; c013ae30 a: 8b 90 a0 00 00 00 mov0xa0(%eax),%edx Code; c013ae36 10: 85 d2 test %edx,%edx Code; c013ae38 12: 74 4e je 62 <_EIP+0x62> c013ae88 2 warnings 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] in locks_remove_posix
Just got this oops in 2.4.5-ac2. Can't reproduce it as of yet; if I find a way, I'll give notice. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell ksymoops 2.3.4 on i586 2.4.5-ac2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac2/ (default) -m /boot/System.map-2.4.5-ac2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __io_virt_debug_R__ver___io_virt_debug not found in System.map. Ignoring ksyms_base entry Unable to handle kernel paging request at virtual address ff14 c013ae26 *pde = 1063 Oops: CPU:0 EIP:0010:[c013ae26] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: ff0c ebx: c66317e0 ecx: edx: c66317e0 esi: edi: ebp: b5b8 esp: c1a9ff90 ds: 0018 es: 0018 ss: 0018 Process dnetc (pid: 227, stackpage=c1a9f000) Stack: c012ad38 c66317e0 c1930200 c66317e0 c66317e0 080ed570 c012ad87 c66317e0 c1930200 c1a9e000 c0106aa3 0005 4000 080ed570 b5b8 0006 002b 002b 0006 0809a982 Call Trace: [c012ad38] [c012ad87] [c0106aa3] Code: 8b 40 08 8b 40 08 8b 74 24 10 8b 90 a0 00 00 00 85 d2 74 4e EIP; c013ae26 locks_remove_posix+6/6c = Trace; c012ad38 filp_close+58/64 Trace; c012ad87 sys_close+43/54 Trace; c0106aa3 system_call+33/40 Code; c013ae26 locks_remove_posix+6/6c _EIP: Code; c013ae26 locks_remove_posix+6/6c = 0: 8b 40 08 mov0x8(%eax),%eax = Code; c013ae29 locks_remove_posix+9/6c 3: 8b 40 08 mov0x8(%eax),%eax Code; c013ae2c locks_remove_posix+c/6c 6: 8b 74 24 10 mov0x10(%esp,1),%esi Code; c013ae30 locks_remove_posix+10/6c a: 8b 90 a0 00 00 00 mov0xa0(%eax),%edx Code; c013ae36 locks_remove_posix+16/6c 10: 85 d2 test %edx,%edx Code; c013ae38 locks_remove_posix+18/6c 12: 74 4e je 62 _EIP+0x62 c013ae88 locks_remove_posix+68/6c 2 warnings 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Mon, May 21, 2001 at 08:16:18AM -0700, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Martin.Knoblauch" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Hi, > > > > while trying to enhance a small hardware inventory script, I found that > > cpuinfo is missing the details of L1, L2 and L3 size, although they may > > be available at boot time. One could of cource grep them from "dmesg" > > output, but that may scroll away on long lived systems. > > > > Any particular reason this needs to be done in the kernel, as opposed > to having your script read /dev/cpu/*/cpuid? Wouldn't that be the same reason we have /anything/ in cpuinfo? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Mon, May 21, 2001 at 08:16:18AM -0700, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Martin.Knoblauch [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Hi, while trying to enhance a small hardware inventory script, I found that cpuinfo is missing the details of L1, L2 and L3 size, although they may be available at boot time. One could of cource grep them from dmesg output, but that may scroll away on long lived systems. Any particular reason this needs to be done in the kernel, as opposed to having your script read /dev/cpu/*/cpuid? Wouldn't that be the same reason we have /anything/ in cpuinfo? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 09:38:03PM +0200, Erik Mouw wrote: > > But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see > > if it's there. writing to files that aren't shown in directory listings > > is plain evil. I really don't want to explain why. It's extremely > > messy and unintuitive. > > > > It would be better to do this with a file that does exist, for example > > writing something to /proc/disks/sda/arguments. Then again, I don't > > even think much of dynamic file systems in the first place. > > A network socket also isn't a file in a filesystem, you can't do ls on > it, it doesn't even exist until you create one, but still you use it as > a file by reading and writing it. I don't see any difference in the way > you create /dev/sda/offset=234234,limit=626737537 by just using it. I think you're kind of missing the point. Erik is saying that, by the path, it appears to be a file, even though it isn't listed as a file in the directory /dev/sda. Network sockets don't have a path, unless its a Unix domain socket, and then you /can/ 'ls' it. My opinion is that putting options directly in the open is no nicer than an ioctl. I think that where this scheme really shines, though, is where there are multiple logical channels to a device, as in the /dev/fb0/control example. I like that. What could be done, therefore, is have a /dev/ttyS0/control file, where you could "echo 'baud=19200,parity=odd' > /dev/ttyS0/control" or even "echo '19200' > /dev/ttyS0/baud" and "echo 'odd' > /dev/ttyS0/parity". That seems to me to be the cleanest and most logical solution. As for this partition stuff, it seems a bad example to me. Maybe I'm just spoiled, but I think partitions is something that the kernel can and should abstract. None of this /dev/sda/offset=12345,limit=45678 madness. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Sat, May 19, 2001 at 09:38:03PM +0200, Erik Mouw wrote: But /dev/sda/offset=234234,limit=626737537 isn't a file! ls it and see if it's there. writing to files that aren't shown in directory listings is plain evil. I really don't want to explain why. It's extremely messy and unintuitive. It would be better to do this with a file that does exist, for example writing something to /proc/disks/sda/arguments. Then again, I don't even think much of dynamic file systems in the first place. A network socket also isn't a file in a filesystem, you can't do ls on it, it doesn't even exist until you create one, but still you use it as a file by reading and writing it. I don't see any difference in the way you create /dev/sda/offset=234234,limit=626737537 by just using it. I think you're kind of missing the point. Erik is saying that, by the path, it appears to be a file, even though it isn't listed as a file in the directory /dev/sda. Network sockets don't have a path, unless its a Unix domain socket, and then you /can/ 'ls' it. My opinion is that putting options directly in the open is no nicer than an ioctl. I think that where this scheme really shines, though, is where there are multiple logical channels to a device, as in the /dev/fb0/control example. I like that. What could be done, therefore, is have a /dev/ttyS0/control file, where you could echo 'baud=19200,parity=odd' /dev/ttyS0/control or even echo '19200' /dev/ttyS0/baud and echo 'odd' /dev/ttyS0/parity. That seems to me to be the cleanest and most logical solution. As for this partition stuff, it seems a bad example to me. Maybe I'm just spoiled, but I think partitions is something that the kernel can and should abstract. None of this /dev/sda/offset=12345,limit=45678 madness. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: cmpci sound chip lockup
Just a "me, too" here. I see this when using the in-kernel driver. I'm now using... 4.12, I think. At any rate, the error doesn't occur, or at least occurs to rarely as to escape notice, with this driver. Might I suggest the kernel's version be upgraded? The updated driver was posted here on lkml some time ago. On Wed, May 16, 2001 at 08:02:06PM -0300, Rik van Riel wrote: > On Wed, 16 May 2001, virii wrote: > > > The attatched file is the format for reporting bugs. > > Too bad my mailreader doesn't quote that thing .. oh well, lets > just replace your bugreport with mine ;) > > I'm seeing a similar thing on 2.4.4-pre[23], but in a far less > serious way. Using xmms the music stops after anything between > a few seconds and a minute, I suspect a race condition somewhere. > > Using mpg123 everything works fine... > > regards, > > Rik > -- > Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml > > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com/ > > - > 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/ -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: cmpci sound chip lockup
Just a me, too here. I see this when using the in-kernel driver. I'm now using... 4.12, I think. At any rate, the error doesn't occur, or at least occurs to rarely as to escape notice, with this driver. Might I suggest the kernel's version be upgraded? The updated driver was posted here on lkml some time ago. On Wed, May 16, 2001 at 08:02:06PM -0300, Rik van Riel wrote: On Wed, 16 May 2001, virii wrote: The attatched file is the format for reporting bugs. Too bad my mailreader doesn't quote that thing .. oh well, lets just replace your bugreport with mine ;) I'm seeing a similar thing on 2.4.4-pre[23], but in a far less serious way. Using xmms the music stops after anything between a few seconds and a minute, I suspect a race condition somewhere. Using mpg123 everything works fine... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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/ -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.4 Sound corruption
On Sun, Apr 29, 2001 at 04:52:15PM +0200, root wrote: > Steven Walter wrote: > > > I'm running esound 0.2.17 from Debian 2.2. Can someone who's having no > > problems with sound on 2.4.4 give a little info about their setup? > > esd works for me with any 2.4.x including 2.4.4 > Pentium III, BE6, ES1370, devfs, Xfree-4.0.3/GNOME > esound-0.2.22. Timidity is fine as well. What else ? That may be enough. I'll upgrade my esd to 0.2.22 and see what happens. Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.4 Sound corruption
On Sun, Apr 29, 2001 at 03:16:24PM +0100, Lee Mitchell wrote: > > > > It would appear that something in the kernel broke esd. > > > > I can confirm that on my system also, the problem only appears when using > esd for output. There must be some for whom esd/sound is still working, or else I'd expect to see/hear a lot more complaints. I'm running esound 0.2.17 from Debian 2.2. Can someone who's having no problems with sound on 2.4.4 give a little info about their setup? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.4 Sound corruption
On Sun, Apr 29, 2001 at 03:16:24PM +0100, Lee Mitchell wrote: It would appear that something in the kernel broke esd. I can confirm that on my system also, the problem only appears when using esd for output. There must be some for whom esd/sound is still working, or else I'd expect to see/hear a lot more complaints. I'm running esound 0.2.17 from Debian 2.2. Can someone who's having no problems with sound on 2.4.4 give a little info about their setup? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.4 Sound corruption
On Sun, Apr 29, 2001 at 04:52:15PM +0200, root wrote: Steven Walter wrote: I'm running esound 0.2.17 from Debian 2.2. Can someone who's having no problems with sound on 2.4.4 give a little info about their setup? esd works for me with any 2.4.x including 2.4.4 Pentium III, BE6, ES1370, devfs, Xfree-4.0.3/GNOME esound-0.2.22. Timidity is fine as well. What else ? That may be enough. I'll upgrade my esd to 0.2.22 and see what happens. Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.4 Sound corruption
I'm also seeing what would appear to be exactly this. The problem, for me, doesn't occur when I write directly to /dev/dsp (i.e., use the OSS output plugin for xmms). The problem only occurs with esd. It would appear that something in the kernel broke esd. On Sat, Apr 28, 2001 at 10:50:01AM +0100, Lee Mitchell wrote: > Problem.. > Playing mp3's under 2.4.4 (SMP) results in bursts of noise overlayed on top > of actual music being played. > Works fine running 2.4.3 (SMP) Running UP here PCChips M599LMR 1 x AMD-K6/2 500MHz 128MB RAM C-Media Kernel 2.4.4 Debian 2.2 gcc version 2.95.2 2220 (Debian GNU/Linux) -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: 2.4.4 Sound corruption
I'm also seeing what would appear to be exactly this. The problem, for me, doesn't occur when I write directly to /dev/dsp (i.e., use the OSS output plugin for xmms). The problem only occurs with esd. It would appear that something in the kernel broke esd. On Sat, Apr 28, 2001 at 10:50:01AM +0100, Lee Mitchell wrote: Problem.. Playing mp3's under 2.4.4 (SMP) results in bursts of noise overlayed on top of actual music being played. Works fine running 2.4.3 (SMP) Running UP here PCChips M599LMR 1 x AMD-K6/2 500MHz 128MB RAM C-Media Kernel 2.4.4 Debian 2.2 gcc version 2.95.2 2220 (Debian GNU/Linux) -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: PATCH 2.4.4.7: serial PCI fixes and cleanup
Just a heads up: works great for me On Thu, Apr 26, 2001 at 07:51:08AM -0400, Jeff Garzik wrote: > The attached patch, against 2.4.4-pre7, cleans up the huge pci_board > list in serial.c to remove PCI id information. In the process, it (a) > demonstrates more complex new-style PCI probing, and (b) fixes a logical > disconnect bug which was causing bug reports. The bug caused by me, > when I added hotplugging to the serial driver (merging serial_cb in > function, but not literally). The bug causes any PCI board which is > listed in the serial.c PCI table, but was not > PCI_CLASS_COMMUNICATION_SERIAL or PCI_CLASS_COMMUNICATION_MODEM, to be > missed in the PCI probe. > > Linus - do not apply just yet. I would prefer this patch go into 2.4.5 > not 2.4.4, so that we can have a bit more public testing first. > tytso - a quick eyeball would be awesome. Ask away with any questions > you have. > Alan - please consider applying to your tree. > Steven - please test, this patch removes the need for your serial.c > patch. > > Others - all testing is welcome. - 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: PATCH 2.4.4.7: serial PCI fixes and cleanup
Just a heads up: works great for me On Thu, Apr 26, 2001 at 07:51:08AM -0400, Jeff Garzik wrote: The attached patch, against 2.4.4-pre7, cleans up the huge pci_board list in serial.c to remove PCI id information. In the process, it (a) demonstrates more complex new-style PCI probing, and (b) fixes a logical disconnect bug which was causing bug reports. The bug caused by me, when I added hotplugging to the serial driver (merging serial_cb in function, but not literally). The bug causes any PCI board which is listed in the serial.c PCI table, but was not PCI_CLASS_COMMUNICATION_SERIAL or PCI_CLASS_COMMUNICATION_MODEM, to be missed in the PCI probe. Linus - do not apply just yet. I would prefer this patch go into 2.4.5 not 2.4.4, so that we can have a bit more public testing first. tytso - a quick eyeball would be awesome. Ask away with any questions you have. Alan - please consider applying to your tree. Steven - please test, this patch removes the need for your serial.c patch. Others - all testing is welcome. - 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] to detect ActionTec PCI modem
This patch modifies serial.c to detect the ActionTec PCI modem. This
particular device has a class of PCI_CLASS_COMMUNICATION_OTHER, so it
isn't detected by the current catch-all rule that detects devices of
"PCI_CLASS_COMMUNICATION_SERIAL".
Patch is against kernel 2.4.3. Tested to compiled and run. Comments
welcome.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- clean-2.4.3/drivers/char/serial.c Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00, },
{ 0, }
-
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] to detect ActionTec PCI modem
This patch modifies serial.c to detect the ActionTec PCI modem. This
particular device has a class of PCI_CLASS_COMMUNICATION_OTHER, so it
isn't detected by the current catch-all rule that detects devices of
PCI_CLASS_COMMUNICATION_SERIAL.
Patch is against kernel 2.4.3. Tested to compiled and run. Comments
welcome.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- clean-2.4.3/drivers/char/serial.c Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL 8, 0x00, },
{ 0, }
-
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: [PATCH] properly detect ActionTec modem of PCI_CLASS_COMMUNICATION_OTHER
On Tue, Apr 24, 2001 at 05:18:36PM -0400, Brian Gerst wrote:
> Steven Walter wrote:
> >
> > This patch allows the serial driver to properly detect and set up the
> > ActionTec PCI modem. This modem has a PCI class of COMMUNICATION_OTHER,
> > which is why this modem is not otherwise detected.
> >
> > Any suggestions on the patch are welcome. Thanks
>
> A small suggestion: Vendor/device id are sufficient to identify the
> device. You can change PCI_CLASS_COMMUNICATION_OTHER << 8 to 0.
Excellent suggestion. Follows is the amended patch. Compiled and
tested to work. BTW: patch is against 2.4.3.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- clean-2.4.3/drivers/char/serial.c Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00, },
{ 0, }
-
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: [PATCH] properly detect ActionTec modem of PCI_CLASS_COMMUNICATION_OTHER
On Tue, Apr 24, 2001 at 05:18:36PM -0400, Brian Gerst wrote:
Steven Walter wrote:
This patch allows the serial driver to properly detect and set up the
ActionTec PCI modem. This modem has a PCI class of COMMUNICATION_OTHER,
which is why this modem is not otherwise detected.
Any suggestions on the patch are welcome. Thanks
A small suggestion: Vendor/device id are sufficient to identify the
device. You can change PCI_CLASS_COMMUNICATION_OTHER 8 to 0.
Excellent suggestion. Follows is the amended patch. Compiled and
tested to work. BTW: patch is against 2.4.3.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- clean-2.4.3/drivers/char/serial.c Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL 8, 0x00, },
{ 0, }
-
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/
serial driver not properly detecting modem
It would seem that I have a modem (hardware based, not winmodem) of PCI_CLASS_COMMUNICATION_OTHER. This, unfortunately, prevents it from being automagically detected by the serial driver, which only looks for devices of PCI_CLASS_COMMUNICATION_SERIAL. I've fixed this here merely by adding an entry to the PCI table of serial.c for PCI_CLASS_COMMUNICATION_OTHER. Is this the best way to fix this? Is there some reason that this shouldn't be done in general? If not, I'd like to see it fix in the kernel proper. It should be noted that the modem is listed in serial.c's pci_boards, perhaps it would be best for the serial driver to list PCI_ID_ANY for a class, and only use pci_boards to further identify serial ports? Or would this be too inefficient to correct for a few misguided hardware makers? Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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/
serial driver not properly detecting modem
It would seem that I have a modem (hardware based, not winmodem) of PCI_CLASS_COMMUNICATION_OTHER. This, unfortunately, prevents it from being automagically detected by the serial driver, which only looks for devices of PCI_CLASS_COMMUNICATION_SERIAL. I've fixed this here merely by adding an entry to the PCI table of serial.c for PCI_CLASS_COMMUNICATION_OTHER. Is this the best way to fix this? Is there some reason that this shouldn't be done in general? If not, I'd like to see it fix in the kernel proper. It should be noted that the modem is listed in serial.c's pci_boards, perhaps it would be best for the serial driver to list PCI_ID_ANY for a class, and only use pci_boards to further identify serial ports? Or would this be too inefficient to correct for a few misguided hardware makers? Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: ide dma in /proc/dma
On Sun, Apr 22, 2001 at 01:53:59PM +0200, [EMAIL PROTECTED] wrote: > Hi! > > why doesnt the dma for ide disks show up in /proc/dma? > > heineken:~# hdparm -d /dev/discs/disc0/disc > /dev/discs/disc0/disc: > using_dma= 1 (on) > > heineken:~# cat /proc/dma > 4: cascade I suspect this is because only ISA DMA's are listed in /proc/dma, and your IDE controller is likely PCI. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: ide dma in /proc/dma
On Sun, Apr 22, 2001 at 01:53:59PM +0200, [EMAIL PROTECTED] wrote: Hi! why doesnt the dma for ide disks show up in /proc/dma? heineken:~# hdparm -d /dev/discs/disc0/disc /dev/discs/disc0/disc: using_dma= 1 (on) heineken:~# cat /proc/dma 4: cascade I suspect this is because only ISA DMA's are listed in /proc/dma, and your IDE controller is likely PCI. -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - 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: [BUG] serial ioctl not returning with 2.4.3
On Wed, Apr 11, 2001 at 04:50:21PM -0400, Jeff Garzik wrote:
> Steven Walter wrote:
> >
> > When I try to start "agetty" on my serial line, agetty hangs in an
> > ioctl; according to strace, this ioctl is "SNDCTL_TMR_STOP". This
> > doesn't sound right, but that ioctl is defined as _IO('T', 3) if that
> > makes any more sense.
> >
> > The reason that this must be a kernel bug is because agetty works
> > flawlessly in an identically-configured 2.4.2 kernel, and even a 2.4.3
> > kernel with the debugging tokens defined. I'd be glad to give any help
> > that I could.
>
> I am not sure this is a serial driver bug:
>
> [jgarzik@rum linux_2_4]$ find . -name '*.[ch]'|xargs grep -wn
> SNDCTL_TMR_STOP
> ./arch/sparc64/kernel/ioctl32.c:3503:COMPATIBLE_IOCTL(SNDCTL_TMR_STOP)
> ./drivers/sound/mpu401.c:1522: case SNDCTL_TMR_STOP:
> ./drivers/sound/sequencer.c:1352: case SNDCTL_TMR_STOP:
> ./drivers/sound/sound_timer.c:195: case SNDCTL_TMR_STOP:
> ./drivers/sound/sys_timer.c:206:case SNDCTL_TMR_STOP:
> ./include/linux/soundcard.h:165:#define SNDCTL_TMR_STOP
> _SIO ('T', 3)
It would appear that way, if not for something I neglected to mention in
my first message--the ioctl is on the fd for the opened serial port.
This succeeds in other version of the kernel (as described in my
original posting) and so must somehow be valid for the serial driver.
Any more thoughts? This would seem to be a definite bug in the serial
code.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
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/
[BUG] serial ioctl not returning with 2.4.3
When I try to start "agetty" on my serial line, agetty hangs in an
ioctl; according to strace, this ioctl is "SNDCTL_TMR_STOP". This
doesn't sound right, but that ioctl is defined as _IO('T', 3) if that
makes any more sense.
The reason that this must be a kernel bug is because agetty works
flawlessly in an identically-configured 2.4.2 kernel, and even a 2.4.3
kernel with the debugging tokens defined. I'd be glad to give any help
that I could.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
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/
[BUG] serial ioctl not returning with 2.4.3
When I try to start "agetty" on my serial line, agetty hangs in an
ioctl; according to strace, this ioctl is "SNDCTL_TMR_STOP". This
doesn't sound right, but that ioctl is defined as _IO('T', 3) if that
makes any more sense.
The reason that this must be a kernel bug is because agetty works
flawlessly in an identically-configured 2.4.2 kernel, and even a 2.4.3
kernel with the debugging tokens defined. I'd be glad to give any help
that I could.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
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: [BUG] serial ioctl not returning with 2.4.3
On Wed, Apr 11, 2001 at 04:50:21PM -0400, Jeff Garzik wrote:
Steven Walter wrote:
When I try to start "agetty" on my serial line, agetty hangs in an
ioctl; according to strace, this ioctl is "SNDCTL_TMR_STOP". This
doesn't sound right, but that ioctl is defined as _IO('T', 3) if that
makes any more sense.
The reason that this must be a kernel bug is because agetty works
flawlessly in an identically-configured 2.4.2 kernel, and even a 2.4.3
kernel with the debugging tokens defined. I'd be glad to give any help
that I could.
I am not sure this is a serial driver bug:
[jgarzik@rum linux_2_4]$ find . -name '*.[ch]'|xargs grep -wn
SNDCTL_TMR_STOP
./arch/sparc64/kernel/ioctl32.c:3503:COMPATIBLE_IOCTL(SNDCTL_TMR_STOP)
./drivers/sound/mpu401.c:1522: case SNDCTL_TMR_STOP:
./drivers/sound/sequencer.c:1352: case SNDCTL_TMR_STOP:
./drivers/sound/sound_timer.c:195: case SNDCTL_TMR_STOP:
./drivers/sound/sys_timer.c:206:case SNDCTL_TMR_STOP:
./include/linux/soundcard.h:165:#define SNDCTL_TMR_STOP
_SIO ('T', 3)
It would appear that way, if not for something I neglected to mention in
my first message--the ioctl is on the fd for the opened serial port.
This succeeds in other version of the kernel (as described in my
original posting) and so must somehow be valid for the serial driver.
Any more thoughts? This would seem to be a definite bug in the serial
code.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
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/
All processes hung under 2.4.3
Earlier today, I tried to unlock xscreensaver on my desktop. After typing in the password, it said "Checking..." and then hung. In response, I hit Ctrl+Alt+Bksp, which killed X. However, gdm did not restart X. I tried logging in on the console, but none of them were responsive; characters would echo, but nothing else. In hopes of finding the problem, I entered kdb, and did a bta. All processes were hung in exactly the same spot, schedule+0x268! This code is as follows: 0xc0110d50 : jne0xc0110d7e 0xc0110d52 : test %eax,%eax 0xc0110d54 : jne0xc0110d72 0xc0110d56 : mov0xffe4(%ecx),%edx 0xc0110d59 : test %edx,%edx 0xc0110d5b : je 0xc0110d7e 0xc0110d5d : mov0xfff0(%ecx),%eax 0xc0110d60 : cmp0xfff0(%ebp),%eax 0xc0110d63 : je 0xc0110d69 0xc0110d65 : test %eax,%eax 0xc0110d67 : jne0xc0110d6a 0xc0110d69 : inc%edx 0xc0110d6a : add$0x14,%edx 0xc0110d6d : sub0x24(%esi),%edx 0xc0110d70 : jmp0xc0110d7e Additionally, I did a "ps" in kdb and found dozens of "cron" and "sh" started. I suspect that these processes were somehow related to the lockup, as the machine should've been idle for hours, and no cron jobs were scheduled for the time. The captured "bta" is availible if anyone is interested. I don't know of a way to reproduce this offhand. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
All processes hung under 2.4.3
Earlier today, I tried to unlock xscreensaver on my desktop. After typing in the password, it said "Checking..." and then hung. In response, I hit Ctrl+Alt+Bksp, which killed X. However, gdm did not restart X. I tried logging in on the console, but none of them were responsive; characters would echo, but nothing else. In hopes of finding the problem, I entered kdb, and did a bta. All processes were hung in exactly the same spot, schedule+0x268! This code is as follows: 0xc0110d50 schedule+252: jne0xc0110d7e schedule+298 0xc0110d52 schedule+254: test %eax,%eax 0xc0110d54 schedule+256: jne0xc0110d72 schedule+286 0xc0110d56 schedule+258: mov0xffe4(%ecx),%edx 0xc0110d59 schedule+261: test %edx,%edx 0xc0110d5b schedule+263: je 0xc0110d7e schedule+298 0xc0110d5d schedule+265: mov0xfff0(%ecx),%eax 0xc0110d60 schedule+268: cmp0xfff0(%ebp),%eax 0xc0110d63 schedule+271: je 0xc0110d69 schedule+277 0xc0110d65 schedule+273: test %eax,%eax 0xc0110d67 schedule+275: jne0xc0110d6a schedule+278 0xc0110d69 schedule+277: inc%edx 0xc0110d6a schedule+278: add$0x14,%edx 0xc0110d6d schedule+281: sub0x24(%esi),%edx 0xc0110d70 schedule+284: jmp0xc0110d7e schedule+298 Additionally, I did a "ps" in kdb and found dozens of "cron" and "sh" started. I suspect that these processes were somehow related to the lockup, as the machine should've been idle for hours, and no cron jobs were scheduled for the time. The captured "bta" is availible if anyone is interested. I don't know of a way to reproduce this offhand. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Oopsen everywhere in open_namei, kernel 2.4.3
Right after a boot, I got 5 oopsen within about 8 minutes. There are only two unique ones, which are attached. Each one occured at least twice. Someone know what's going on? -- -Steven Freedom is the freedom to say that two plus two equals four. ksymoops 2.3.4 on i586 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 78e85047 c01378c3 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: ebx: c3121460 ecx: 0001 edx: 03e8 esi: edi: 0001 ebp: 0001 esp: c4b43f4c ds: 0018 es: 0018 ss: 0018 Process modemlights_app (pid: 301, stackpage=c4b43000) Stack: 080be760 0001 c72e4000 0004 c47d0ac0 c012c87e c72e4000 0001 01b6 c4b43f84 0010 c47d0ac0 c1241240 0001 c72e4000 0001 0001 c012cb89 c72e4000 Call Trace: [] [] [] Code: ff 89 46 50 e8 78 3b ff ff 89 46 54 8b 4d e0 8b 7d 0c 89 4d >>EIP; c01378c3<= Trace; c012c87e Trace; c012cb89 Trace; c0106d73 Code; c01378c3 <_EIP>: Code; c01378c3<= 0: ff 89 46 50 e8 78 decl 0x78e85046(%ecx) <= Code; c01378c9 6: 3b ff cmp%edi,%edi Code; c01378cb 8: ff 89 46 54 8b 4d decl 0x4d8b5446(%ecx) Code; c01378d1 e: e0 8b loopne ff9b <_EIP+0xff9b> c013785e Code; c01378d3 10: 7d 0c jge1e <_EIP+0x1e> c01378e1 Code; c01378d5 12: 89 4d 00 mov%ecx,0x0(%ebp) 1 warning issued. Results may not be reliable. ksymoops 2.3.4 on i586 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 78e8504a c01378c3 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210293 eax: ebx: c7f2f260 ecx: 0004 edx: esi: edi: 0001 ebp: 0001 esp: c317ff4c ds: 0018 es: 0018 ss: 0018 Process gpm (pid: 462, stackpage=c317f000) Stack: 08058240 0001 c784b000 00200286 0004 c76e1f40 c012c87e c784b000 0001 0001 c317ff84 0002 c76e1f40 c1241240 0001 c784b000 0001 0001 c012cb89 c784b000 Call Trace: [] [] [] Code: f6 75 77 f7 c5 00 02 00 00 74 5c 53 e8 ec ec ff ff 89 c6 83 >>EIP; c01378c3<= Trace; c012c87e Trace; c012cb89 Trace; c0106d73 Code; c01378c3 <_EIP>: Code; c01378c3<= 0: f6 75 77 div0x77(%ebp),%al <= Code; c01378c6 3: f7 c5 00 02 00 00 test $0x200,%ebp Code; c01378cc 9: 74 5c je 67 <_EIP+0x67> c013792a Code; c01378ce b: 53push %ebx Code; c01378cf c: e8 ec ec ff ffcall ecfd <_EIP+0xecfd> c01365c0 Code; c01378d4 11: 89 c6 mov%eax,%esi Code; c01378d6 13: 83 00 00 addl $0x0,(%eax) 1 warning issued. Results may not be reliable.
Problems with serial driver 5.05, kernel 2.4.3
I'm getting some interesting behavior with the 2.4.3 serial driver and agetty. This system uses the onboard serial port (ttyS0) for a serial console (console=ttyS0,38400) along with the VGA port. If I try to start an agetty on this line (agetty -L ttyS0 38400), it gets as far as outputting "Debian GNU/Linux", etc, before freezing in ioctl(0, SNDCTL_STOP...), this according to strace. According to "ps -eo wchan", it's hanging in tty_wait_until_sent. fd 0 is /dev/ttyS0. This happens if the port is connected via null-modem cable to another computer, a null-modem cable connected to no other computer, or no cable at all. This seems to be a kernel problem to me, since its hanging in kernel space. However, the problem can be worked around somewhat by starting agetty as "agetty -n -L ttyS0 38400". In this mode of operation, the login prompt gets printed (though the banner doesn't), and I can log in. It seems to work well, except that large sustained transfers seem to lock the program on this end. For example, "dmesg" will print out a considerable amount of text, and then simply stop. Ctrl+C returns me to a bash prompt. It stops at the same spot every time, unless I start typing between "dmesg" and stoppage. It never varies by more than a few (10-15) characters. Interestingly enough, characters are still echoed between stoppage and return to bash. I wouldn't blame the cable or the remote computer, though, as I've tried using an entirely different computer complete with different OS as the terminal, with precisely the same behavior. I've also used the cable between the two other computers, in which it works correctly. (The kernel used in which it works correctly is 2.2.14 on an RH 5.2 system.) I hope I've given you enough information to make a useful evaluation, and hopefully a fix. If I've left something out, please ask, and I'll be happy to give you whatever I can. I'm also willing to try out possible fixes. Thanks -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: kernel/sched.c questions
On Wed, Apr 04, 2001 at 04:52:32PM -0300, Sarda?ons, Eliel wrote:
> switch (prev->state) {
> case TASK_INTERRUPTIBLE:
> if (signal_pending(prev)) {
> prev->state = TASK_RUNNING;
> break;
> }
> default:
> del_from_runqueue(prev);
> case TASK_RUNNING:
> }
I'm not sure about the other two, but this one is pretty straight
forward: its listed explicitly because we don't want tasks with
p->state TASK_RUNNING to fall into the default case, that is, getting
deleted from the runqueue. This would be bad.
--
-Steven
Freedom is the freedom to say that two plus two equals four.
-
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: kernel/sched.c questions
On Wed, Apr 04, 2001 at 04:52:32PM -0300, Sarda?ons, Eliel wrote:
switch (prev-state) {
case TASK_INTERRUPTIBLE:
if (signal_pending(prev)) {
prev-state = TASK_RUNNING;
break;
}
default:
del_from_runqueue(prev);
case TASK_RUNNING:
}
I'm not sure about the other two, but this one is pretty straight
forward: its listed explicitly because we don't want tasks with
p-state TASK_RUNNING to fall into the default case, that is, getting
deleted from the runqueue. This would be bad.
--
-Steven
Freedom is the freedom to say that two plus two equals four.
-
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/
Problems with serial driver 5.05, kernel 2.4.3
I'm getting some interesting behavior with the 2.4.3 serial driver and agetty. This system uses the onboard serial port (ttyS0) for a serial console (console=ttyS0,38400) along with the VGA port. If I try to start an agetty on this line (agetty -L ttyS0 38400), it gets as far as outputting "Debian GNU/Linux", etc, before freezing in ioctl(0, SNDCTL_STOP...), this according to strace. According to "ps -eo wchan", it's hanging in tty_wait_until_sent. fd 0 is /dev/ttyS0. This happens if the port is connected via null-modem cable to another computer, a null-modem cable connected to no other computer, or no cable at all. This seems to be a kernel problem to me, since its hanging in kernel space. However, the problem can be worked around somewhat by starting agetty as "agetty -n -L ttyS0 38400". In this mode of operation, the login prompt gets printed (though the banner doesn't), and I can log in. It seems to work well, except that large sustained transfers seem to lock the program on this end. For example, "dmesg" will print out a considerable amount of text, and then simply stop. Ctrl+C returns me to a bash prompt. It stops at the same spot every time, unless I start typing between "dmesg" and stoppage. It never varies by more than a few (10-15) characters. Interestingly enough, characters are still echoed between stoppage and return to bash. I wouldn't blame the cable or the remote computer, though, as I've tried using an entirely different computer complete with different OS as the terminal, with precisely the same behavior. I've also used the cable between the two other computers, in which it works correctly. (The kernel used in which it works correctly is 2.2.14 on an RH 5.2 system.) I hope I've given you enough information to make a useful evaluation, and hopefully a fix. If I've left something out, please ask, and I'll be happy to give you whatever I can. I'm also willing to try out possible fixes. Thanks -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Oopsen everywhere in open_namei, kernel 2.4.3
Right after a boot, I got 5 oopsen within about 8 minutes. There are only two unique ones, which are attached. Each one occured at least twice. Someone know what's going on? -- -Steven Freedom is the freedom to say that two plus two equals four. ksymoops 2.3.4 on i586 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 78e85047 c01378c3 *pde = Oops: 0002 CPU:0 EIP:0010:[c01378c3] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: ebx: c3121460 ecx: 0001 edx: 03e8 esi: edi: 0001 ebp: 0001 esp: c4b43f4c ds: 0018 es: 0018 ss: 0018 Process modemlights_app (pid: 301, stackpage=c4b43000) Stack: 080be760 0001 c72e4000 0004 c47d0ac0 c012c87e c72e4000 0001 01b6 c4b43f84 0010 c47d0ac0 c1241240 0001 c72e4000 0001 0001 c012cb89 c72e4000 Call Trace: [c012c87e] [c012cb89] [c0106d73] Code: ff 89 46 50 e8 78 3b ff ff 89 46 54 8b 4d e0 8b 7d 0c 89 4d EIP; c01378c3 open_namei+3f7/590 = Trace; c012c87e filp_open+2e/4c Trace; c012cb89 sys_open+35/b4 Trace; c0106d73 system_call+33/40 Code; c01378c3 open_namei+3f7/590 _EIP: Code; c01378c3 open_namei+3f7/590 = 0: ff 89 46 50 e8 78 decl 0x78e85046(%ecx) = Code; c01378c9 open_namei+3fd/590 6: 3b ff cmp%edi,%edi Code; c01378cb open_namei+3ff/590 8: ff 89 46 54 8b 4d decl 0x4d8b5446(%ecx) Code; c01378d1 open_namei+405/590 e: e0 8b loopne ff9b _EIP+0xff9b c013785e open_namei+392/590 Code; c01378d3 open_namei+407/590 10: 7d 0c jge1e _EIP+0x1e c01378e1 open_namei+415/590 Code; c01378d5 open_namei+409/590 12: 89 4d 00 mov%ecx,0x0(%ebp) 1 warning issued. Results may not be reliable. ksymoops 2.3.4 on i586 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3/ (default) -m /boot/System.map-2.4.3 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 78e8504a c01378c3 *pde = Oops: 0002 CPU:0 EIP:0010:[c01378c3] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210293 eax: ebx: c7f2f260 ecx: 0004 edx: esi: edi: 0001 ebp: 0001 esp: c317ff4c ds: 0018 es: 0018 ss: 0018 Process gpm (pid: 462, stackpage=c317f000) Stack: 08058240 0001 c784b000 00200286 0004 c76e1f40 c012c87e c784b000 0001 0001 c317ff84 0002 c76e1f40 c1241240 0001 c784b000 0001 0001 c012cb89 c784b000 Call Trace: [c012c87e] [c012cb89] [c0106d73] Code: f6 75 77 f7 c5 00 02 00 00 74 5c 53 e8 ec ec ff ff 89 c6 83 EIP; c01378c3 open_namei+3f7/590 = Trace; c012c87e filp_open+2e/4c Trace; c012cb89 sys_open+35/b4 Trace; c0106d73 system_call+33/40 Code; c01378c3 open_namei+3f7/590 _EIP: Code; c01378c3 open_namei+3f7/590 = 0: f6 75 77 div0x77(%ebp),%al = Code; c01378c6 open_namei+3fa/590 3: f7 c5 00 02 00 00 test $0x200,%ebp Code; c01378cc open_namei+400/590 9: 74 5c je 67 _EIP+0x67 c013792a open_namei+45e/590 Code; c01378ce open_namei+402/590 b: 53push %ebx Code; c01378cf open_namei+403/590 c: e8 ec ec ff ffcall ecfd _EIP+0xecfd c01365c0 get_write_access+0/20 Code; c01378d4 open_namei+408/590 11: 89 c6 mov%eax,%esi Code; c01378d6 open_namei+40a/590 13: 83 00 00 addl $0x0,(%eax) 1 warning issued. Results may not be reliable.
Re: bug database braindump from the kernel summit
On Mon, Apr 02, 2001 at 06:26:45AM +0100, Richard Russon wrote: > On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: > > Let's hope it's not a flamewar, but here goes :) > > > > We -need- .config, but /proc/config seems like pure bloat. > > Don't ask me for sample code, but... > > The init code for many drivers is freed up after it's used. > Could we apply the same technique and compile in .config, > then printk the entire lot (boot option) and free up the > space afterwards? Though this would save memory at run-time, you'd still increase the size of the image. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: bug database braindump from the kernel summit
On Mon, Apr 02, 2001 at 06:26:45AM +0100, Richard Russon wrote: On 01 Apr 2001 18:21:29 -0500, Jeff Garzik wrote: Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems like pure bloat. Don't ask me for sample code, but... The init code for many drivers is freed up after it's used. Could we apply the same technique and compile in .config, then printk the entire lot (boot option) and free up the space afterwards? Though this would save memory at run-time, you'd still increase the size of the image. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: 2.4.2: System clock slows down under load
On Tue, Mar 27, 2001 at 01:42:39PM +0200, Thomas Pfaff wrote: > Hi all, > > i decided to make a test for the 2.4 kernel on my old hardware (Gigabyte > EISA/VLB with an AMD 486 DX4 133). The kernel boots fine but there is one > strange thing: The system clock slows down under load, after a make > dep in the linux src directory it is about 2 minutes behind. This appears > both in 2.4.1 and in 2.4.2 (I have not tried 2.4.0 yet). > > I have attached a gzipped dmesg. > > Any ideas ? I notice that you're using fbcon from your dmesg. There was a discussion about this a while back, and it was determined that fbcon runs with interrupts disabled for unhealthily long period of time. This causes it to miss timer interrupts, and the system lock get behind. See if this slowdown occurs with vgacon. If it does, its probably just a cheap crystal on the motherboard. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: Strange lockups on 2.4.2
On Tue, Mar 27, 2001 at 06:05:05PM +1000, Keith Owens wrote: > On Mon, 26 Mar 2001 23:16:27 -0600, > Steven Walter <[EMAIL PROTECTED]> wrote: > >This has happened twice, now, though I don't believe its completely > >reproduceable. What happens is an Oops, which drops me into kdb. I've > >been in X both times, however, which makes kdb rather useless. > > Documentation/serial-console.txt > Unfortunately I don't have the money to go and buy a dumb-terminal, and the nearest other computer is ~30 feet away. I've actually looked into writing code that allows to kernel to return to VGA-text mode for this reason. > >The thing I find most interesting about this is that only 4 lines of the > >oops gets into the log. 4 lines, both times. This time, those lines > >were: > > > > printing eip: > >c0112e1f > >Oops: 0002 > >CPU:0 > > That is a symptom of a broken klogd. Always run klogd with the -x > switch. If that does not work, take a look at > > >ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/patch-sysklogd-1-3-31-ksymoops-1.gz > > One day the sysklogd maintainers might just fix this bug, that bug fix > is almost 2 years old. I actually already run klogd with -x due to earlier threads on lkml, so it can't be that /particular/ problem, but klog/syslog may still be to blame. I'm usually lucky to get anything in my log between "--MARK--" then "klogd restart" related to the crash. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: Strange lockups on 2.4.2
On Tue, Mar 27, 2001 at 06:05:05PM +1000, Keith Owens wrote: On Mon, 26 Mar 2001 23:16:27 -0600, Steven Walter [EMAIL PROTECTED] wrote: This has happened twice, now, though I don't believe its completely reproduceable. What happens is an Oops, which drops me into kdb. I've been in X both times, however, which makes kdb rather useless. Documentation/serial-console.txt Unfortunately I don't have the money to go and buy a dumb-terminal, and the nearest other computer is ~30 feet away. I've actually looked into writing code that allows to kernel to return to VGA-text mode for this reason. The thing I find most interesting about this is that only 4 lines of the oops gets into the log. 4 lines, both times. This time, those lines were: printing eip: c0112e1f Oops: 0002 CPU:0 That is a symptom of a broken klogd. Always run klogd with the -x switch. If that does not work, take a look at ftp://ftp.country.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/patch-sysklogd-1-3-31-ksymoops-1.gz One day the sysklogd maintainers might just fix this bug, that bug fix is almost 2 years old. I actually already run klogd with -x due to earlier threads on lkml, so it can't be that /particular/ problem, but klog/syslog may still be to blame. I'm usually lucky to get anything in my log between "--MARK--" then "klogd restart" related to the crash. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: 2.4.2: System clock slows down under load
On Tue, Mar 27, 2001 at 01:42:39PM +0200, Thomas Pfaff wrote: Hi all, i decided to make a test for the 2.4 kernel on my old hardware (Gigabyte EISA/VLB with an AMD 486 DX4 133). The kernel boots fine but there is one strange thing: The system clock slows down under load, after a make dep in the linux src directory it is about 2 minutes behind. This appears both in 2.4.1 and in 2.4.2 (I have not tried 2.4.0 yet). I have attached a gzipped dmesg. Any ideas ? I notice that you're using fbcon from your dmesg. There was a discussion about this a while back, and it was determined that fbcon runs with interrupts disabled for unhealthily long period of time. This causes it to miss timer interrupts, and the system lock get behind. See if this slowdown occurs with vgacon. If it does, its probably just a cheap crystal on the motherboard. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Strange lockups on 2.4.2
This has happened twice, now, though I don't believe its completely reproduceable. What happens is an Oops, which drops me into kdb. I've been in X both times, however, which makes kdb rather useless. I blindly type "go", and interrupts get reenabled, at least (I know because my mp3 stops looping and begins playing again). This almost must mean at least part of userspace survives. Probably only X dies, since VT switching and numlock-toggling doesn't work. I can Ctrl+SysRq S-U-B, though. The thing I find most interesting about this is that only 4 lines of the oops gets into the log. 4 lines, both times. This time, those lines were: printing eip: c0112e1f Oops: 0002 CPU:0 This corresponds to schedule according to System.map (that's the nearest symbol without going over). Before I believe it was path_walk. If anyone's got an idea, it'd be helpful. Btw, this machine consistently passes memtest, most recently ran 2 passes of all tests with no errors found. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
Strange lockups on 2.4.2
This has happened twice, now, though I don't believe its completely reproduceable. What happens is an Oops, which drops me into kdb. I've been in X both times, however, which makes kdb rather useless. I blindly type "go", and interrupts get reenabled, at least (I know because my mp3 stops looping and begins playing again). This almost must mean at least part of userspace survives. Probably only X dies, since VT switching and numlock-toggling doesn't work. I can Ctrl+SysRq S-U-B, though. The thing I find most interesting about this is that only 4 lines of the oops gets into the log. 4 lines, both times. This time, those lines were: printing eip: c0112e1f Oops: 0002 CPU:0 This corresponds to schedule according to System.map (that's the nearest symbol without going over). Before I believe it was path_walk. If anyone's got an idea, it'd be helpful. Btw, this machine consistently passes memtest, most recently ran 2 passes of all tests with no errors found. -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: eepro100 question: why SCBCmd byte is 0x80?
I'm having a similar problem with the onboard network card of a Sony Vaio Laptop. I haven't tracked it down as far as you can; how can I confirm its the same problem as yours? On Fri, Mar 23, 2001 at 09:34:36AM -0800, Jun Sun wrote: > christophe barbe wrote: > > > > Which kernel are you using. > > > > I've had a similar problem with 2.2.18. > > I've backported 2.2.19pre changes to it. > > (i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between >2.2.18 and the last 2.2.19pre) > > And since I've never seen this problem again. > > > > Christophe > > > > Kernel is 2.4.2. It is a MIPS machine. > > I don't really think it is a driver problem, because the same dirver works > fine on many other boards (including MIPS boards). In addition, I also tested > with tulip cards and I had the same symptom. I am convinced it is a low-level > problem (bus timing, PCI setting, buggy hardware, etc). > > On the other hand, it could be a driver problem which is only exposed in this > particular board, although very unlikely. > > BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already > in it? > > Thanks. > > Jun > > > On jeu, 22 mar 2001 22:04:45 Jun Sun wrote: > > > > > > I am trying to get netgear card working on a new (read as potentially buggy > > > hardware) MIPS board. > > > > > > The eepro100 driver basically works fine. It is just after a little while > > > (usually 2 sec to 15 sec) network communication suddenly stops and I start see > > > error message like "eepro100: wait_for_cmd_done timeout!". > > > > > > I looked into this, and it appears that the SCBCmd byte in the command word > > > has value 0x80 instead of the expected 0. I looked at the Intel manual, and > > > it says nothing about the value being 0x80. > > > > > > Does anybody have a clue here? I suspect some timing is wrong or a buggy PCI > > > controller. > > > > > > Please cc your reply to my email address. Thanks. > > > > > > Jun > > > - > > > 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/ > > > > > -- > > Christophe Barbé > > Software Engineer > > Lineo High Availability Group > > 42-46, rue Médéric > > 92110 Clichy - France > > phone (33).1.41.40.02.12 > > fax (33).1.41.40.02.01 > > www.lineo.com > - > 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/ -- -Steven Freedom is the freedom to say that two plus two equals four. - 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: eepro100 question: why SCBCmd byte is 0x80?
I'm having a similar problem with the onboard network card of a Sony Vaio Laptop. I haven't tracked it down as far as you can; how can I confirm its the same problem as yours? On Fri, Mar 23, 2001 at 09:34:36AM -0800, Jun Sun wrote: christophe barbe wrote: Which kernel are you using. I've had a similar problem with 2.2.18. I've backported 2.2.19pre changes to it. (i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between 2.2.18 and the last 2.2.19pre) And since I've never seen this problem again. Christophe Kernel is 2.4.2. It is a MIPS machine. I don't really think it is a driver problem, because the same dirver works fine on many other boards (including MIPS boards). In addition, I also tested with tulip cards and I had the same symptom. I am convinced it is a low-level problem (bus timing, PCI setting, buggy hardware, etc). On the other hand, it could be a driver problem which is only exposed in this particular board, although very unlikely. BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already in it? Thanks. Jun On jeu, 22 mar 2001 22:04:45 Jun Sun wrote: I am trying to get netgear card working on a new (read as potentially buggy hardware) MIPS board. The eepro100 driver basically works fine. It is just after a little while (usually 2 sec to 15 sec) network communication suddenly stops and I start see error message like "eepro100: wait_for_cmd_done timeout!". I looked into this, and it appears that the SCBCmd byte in the command word has value 0x80 instead of the expected 0. I looked at the Intel manual, and it says nothing about the value being 0x80. Does anybody have a clue here? I suspect some timing is wrong or a buggy PCI controller. Please cc your reply to my email address. Thanks. Jun - 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/ -- Christophe Barb Software Engineer Lineo High Availability Group 42-46, rue Mdric 92110 Clichy - France phone (33).1.41.40.02.12 fax (33).1.41.40.02.01 www.lineo.com - 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/ -- -Steven Freedom is the freedom to say that two plus two equals four. - 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/
[OOPS] in usbcore, 2.4.2-ac17
Got the following oops while starting quake2 (one time) and running mpg123 (another time). It seems pretty reproduceable. Kernel version 2.4.2-ac17, motherboard is a i810 chipset eMachines Caveat emptor, this was typed by hand, but the two oopsen, after being entered, where identical, so unless I made the same typo twice (or miscopied twice)... CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: 1850 ecx: c1127e8c edx: esi: 0401 edi: 000a ebp: c1127e64 esp: c021bf0c ds: 0018 es: 0018 ss: 0018 Stack: c117cce0 0401 000a c021bfa0 0001 c021bf98 c0168946 8140 0001 c011bcd4 0001 c485b127 c1127e64 c021bf98 c026352c c011b7e6 c020a3c0 c011940f c0109f2d 000a c116a6e4 c021bfa0 0140 Call Trace: [][][][][][][] [][][][][][][] Code: f7 71 14 89 51 20 8b 41 28 40 83 e0 1f 89 41 28 8a 41 28 8d >>EIP; c4858364 <[usbcore]usb_drivers_purge+240/288> <= Trace; c0168946 Trace; c011bcd4 Trace; c485b127 <[usbcore]usb_get_port_status+f/38> Trace; c011b7e6 Trace; c011940f Trace; c0109f2d Trace; c010a08e Trace; c0108db0 Trace; c01a6bcd Trace; c01a697c Trace; c0107120 Trace; c01071a9 Trace; c0105000 Trace; c0100191 Code; c4858364 <[usbcore]usb_drivers_purge+240/288> <_EIP>: Code; c4858364 <[usbcore]usb_drivers_purge+240/288> <= 0: f7 71 14 div0x14(%ecx),%eax <= Code; c4858367 <[usbcore]usb_drivers_purge+243/288> 3: 89 51 20 mov%edx,0x20(%ecx) Code; c485836a <[usbcore]usb_drivers_purge+246/288> 6: 8b 41 28 mov0x28(%ecx),%eax Code; c485836d <[usbcore]usb_drivers_purge+249/288> 9: 40inc%eax Code; c485836e <[usbcore]usb_drivers_purge+24a/288> a: 83 e0 1f and$0x1f,%eax Code; c4858371 <[usbcore]usb_drivers_purge+24d/288> d: 89 41 28 mov%eax,0x28(%ecx) Code; c4858374 <[usbcore]usb_drivers_purge+250/288> 10: 8a 41 28 mov0x28(%ecx),%al Code; c4858377 <[usbcore]usb_drivers_purge+253/288> 13: 8d 00 lea(%eax),%eax -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
[OOPS] in usbcore, 2.4.2-ac17
Got the following oops while starting quake2 (one time) and running mpg123 (another time). It seems pretty reproduceable. Kernel version 2.4.2-ac17, motherboard is a i810 chipset eMachines Caveat emptor, this was typed by hand, but the two oopsen, after being entered, where identical, so unless I made the same typo twice (or miscopied twice)... CPU:0 EIP:0010:[c4858364] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: 1850 ecx: c1127e8c edx: esi: 0401 edi: 000a ebp: c1127e64 esp: c021bf0c ds: 0018 es: 0018 ss: 0018 Stack: c117cce0 0401 000a c021bfa0 0001 c021bf98 c0168946 8140 0001 c011bcd4 0001 c485b127 c1127e64 c021bf98 c026352c c011b7e6 c020a3c0 c011940f c0109f2d 000a c116a6e4 c021bfa0 0140 Call Trace: [c0168946][c011bcd4][c485b127][c011b7e6][c011940f][c0109f2d][c010a08e] [c0108db0][c01a6bcd][c01a697c][c0107120][c01071a9][c0105000][c0100191] Code: f7 71 14 89 51 20 8b 41 28 40 83 e0 1f 89 41 28 8a 41 28 8d EIP; c4858364 [usbcore]usb_drivers_purge+240/288 = Trace; c0168946 batch_entropy_process+aa/b0 Trace; c011bcd4 timer_bh+24/25c Trace; c485b127 [usbcore]usb_get_port_status+f/38 Trace; c011b7e6 tqueue_bh+16/1c Trace; c011940f bh_action+1b/60 Trace; c0109f2d handle_IRQ_event+31/5c Trace; c010a08e do_IRQ+6e/b0 Trace; c0108db0 ret_from_intr+0/20 Trace; c01a6bcd acpi_idle+251/27c Trace; c01a697c acpi_idle+0/27c Trace; c0107120 default_idle+0/28 Trace; c01071a9 cpu_idle+41/54 Trace; c0105000 empty_bad_page+0/1000 Trace; c0100191 L6+0/2 Code; c4858364 [usbcore]usb_drivers_purge+240/288 _EIP: Code; c4858364 [usbcore]usb_drivers_purge+240/288 = 0: f7 71 14 div0x14(%ecx),%eax = Code; c4858367 [usbcore]usb_drivers_purge+243/288 3: 89 51 20 mov%edx,0x20(%ecx) Code; c485836a [usbcore]usb_drivers_purge+246/288 6: 8b 41 28 mov0x28(%ecx),%eax Code; c485836d [usbcore]usb_drivers_purge+249/288 9: 40inc%eax Code; c485836e [usbcore]usb_drivers_purge+24a/288 a: 83 e0 1f and$0x1f,%eax Code; c4858371 [usbcore]usb_drivers_purge+24d/288 d: 89 41 28 mov%eax,0x28(%ecx) Code; c4858374 [usbcore]usb_drivers_purge+250/288 10: 8a 41 28 mov0x28(%ecx),%al Code; c4858377 [usbcore]usb_drivers_purge+253/288 13: 8d 00 lea(%eax),%eax -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
Trouble with an ip_conntrack_helper
I'm getting some interesting behavior while writing an ip_conntrack
helper module. The primary problem is if I specify a destination port
for the struct ip_conntrack_helper, my help routine is never called.
If I specify a source port, rather than a destination port, the routine
gets called for the various packets in the desired connection.
The problem with this is that I my routine doesn't start getting called
until a packet in the opposite direction arrives, and all packets before
that are never sent by my module. This makes sense, as the tuple
specifies a /source/ port, which would only occur on reverse traffic.
Here is the chunk of code I'm using to register my helper. Is there
something really obvious that I'm missing. I really appreciate any help
you can give.
static struct ip_conntrack_helper icq;
static int __init init(void) {
memset(, 0, sizeof(struct ip_conntrack_helper));
icq.tuple.dst.protonum = IPPROTO_UDP;
icq.tuple.dst.u.udp.port = __constant_htons(4000);
icq.mask.dst.protonum = 0x;
icq.mask.dst.u.udp.port = 0x;
icq.help = help;
printk(KERN_INFO "ip_conntrack_icq: registered\n");
return ip_conntrack_helper_register();
}
--
-Steven
Never ask a geek why, just nod your head and slowly back away.
-
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: IDE on 2.4.2
On Mon, Mar 12, 2001 at 08:50:23AM +0100, Martin Diehl wrote: > > On Sun, 11 Mar 2001, Steven Walter wrote: > > I have this exact same chip on my board (a PCChips M599-LMR or something > > like that) which works flawlessly on 2.4.2, even with UDMA66. > > Do you have CONFIG_BLK_DEV_SIS5513 and autotuning enabled at the > same time? Unless I enable them both it works flawlessly for me too - up > to UDMA33. In fact, I've never seen any docs claiming the 5591/5513 would > even provide UDMA66 support. How do you program the controler to do UDMA66 > cycles? > Anyway, might be interesting to have a look at your lspci -d:5513 -vvvxxx > report from working UDMA33/66 setups! The big man himself, Andre Hedrick, has stated that the SiS5513 should work in UDMA/66 mode, as is evidenced by my setup. Yep, both are enabled (from .config): CONFIG_BLK_DEV_SIS5513=y CONFIG_IDEDMA_AUTO=y I don't have to do anything to program it to UDMA66, as this is what it defaults to on boot (from dmesg): SIS5513: IDE controller on PCI bus 00 dev 01 PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try using pci=biosirq. SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS530 ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA hda: WDC WD84AA, ATA DISK drive hdc: ATAPI 48X CDROM, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 16514064 sectors (8455 MB) w/2048KiB Cache, CHS=1027/255/63, UDMA(66) hdc: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33) And, as you've requested, here is the lspci output from my system, which is working and in UDMA66. 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 80 [Master]) Subsystem: Silicon Integrated Systems [SiS]: Unknown device 5513 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at ffa0 [size=16] 00: 39 10 13 55 05 00 00 00 d0 80 01 01 00 80 80 00 10: f1 01 00 00 f5 03 00 00 71 01 00 00 75 03 00 00 20: a1 ff 00 00 00 00 00 00 00 00 00 00 39 10 13 55 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40: 01 93 00 00 01 b3 00 00 23 07 e6 11 00 02 00 02 50: 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Be sure that you have an 80-conductor cable, however. On my system, there is a BIOS option for UDMA. This apparently overrides/takes the place of proper cable detection. If I turn it on without an 80-pin cable, Linux defaults to UDMA66 and I get drive major drive corruption. When off, I can't use UDMA66. I hope all this is helpful to you! -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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: IDE on 2.4.2
On Mon, Mar 12, 2001 at 08:50:23AM +0100, Martin Diehl wrote: On Sun, 11 Mar 2001, Steven Walter wrote: I have this exact same chip on my board (a PCChips M599-LMR or something like that) which works flawlessly on 2.4.2, even with UDMA66. Do you have CONFIG_BLK_DEV_SIS5513 and autotuning enabled at the same time? Unless I enable them both it works flawlessly for me too - up to UDMA33. In fact, I've never seen any docs claiming the 5591/5513 would even provide UDMA66 support. How do you program the controler to do UDMA66 cycles? Anyway, might be interesting to have a look at your lspci -d:5513 -vvvxxx report from working UDMA33/66 setups! The big man himself, Andre Hedrick, has stated that the SiS5513 should work in UDMA/66 mode, as is evidenced by my setup. Yep, both are enabled (from .config): CONFIG_BLK_DEV_SIS5513=y CONFIG_IDEDMA_AUTO=y I don't have to do anything to program it to UDMA66, as this is what it defaults to on boot (from dmesg): SIS5513: IDE controller on PCI bus 00 dev 01 PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try using pci=biosirq. SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS530 ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA hda: WDC WD84AA, ATA DISK drive hdc: ATAPI 48X CDROM, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 16514064 sectors (8455 MB) w/2048KiB Cache, CHS=1027/255/63, UDMA(66) hdc: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33) And, as you've requested, here is the lspci output from my system, which is working and in UDMA66. 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 80 [Master]) Subsystem: Silicon Integrated Systems [SiS]: Unknown device 5513 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 128 set Interrupt: pin A routed to IRQ 0 Region 0: I/O ports at ignored Region 1: I/O ports at ignored Region 2: I/O ports at ignored Region 3: I/O ports at ignored Region 4: I/O ports at ffa0 [size=16] 00: 39 10 13 55 05 00 00 00 d0 80 01 01 00 80 80 00 10: f1 01 00 00 f5 03 00 00 71 01 00 00 75 03 00 00 20: a1 ff 00 00 00 00 00 00 00 00 00 00 39 10 13 55 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40: 01 93 00 00 01 b3 00 00 23 07 e6 11 00 02 00 02 50: 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Be sure that you have an 80-conductor cable, however. On my system, there is a BIOS option for UDMA. This apparently overrides/takes the place of proper cable detection. If I turn it on without an 80-pin cable, Linux defaults to UDMA66 and I get drive major drive corruption. When off, I can't use UDMA66. I hope all this is helpful to you! -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
Trouble with an ip_conntrack_helper
I'm getting some interesting behavior while writing an ip_conntrack
helper module. The primary problem is if I specify a destination port
for the struct ip_conntrack_helper, my help routine is never called.
If I specify a source port, rather than a destination port, the routine
gets called for the various packets in the desired connection.
The problem with this is that I my routine doesn't start getting called
until a packet in the opposite direction arrives, and all packets before
that are never sent by my module. This makes sense, as the tuple
specifies a /source/ port, which would only occur on reverse traffic.
Here is the chunk of code I'm using to register my helper. Is there
something really obvious that I'm missing. I really appreciate any help
you can give.
static struct ip_conntrack_helper icq;
static int __init init(void) {
memset(icq, 0, sizeof(struct ip_conntrack_helper));
icq.tuple.dst.protonum = IPPROTO_UDP;
icq.tuple.dst.u.udp.port = __constant_htons(4000);
icq.mask.dst.protonum = 0x;
icq.mask.dst.u.udp.port = 0x;
icq.help = help;
printk(KERN_INFO "ip_conntrack_icq: registered\n");
return ip_conntrack_helper_register(icq);
}
--
-Steven
Never ask a geek why, just nod your head and slowly back away.
-
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: IDE on 2.4.2
On Sun, Mar 11, 2001 at 10:03:48PM +0100, Martin Diehl wrote: > On Fri, 9 Mar 2001, Lawrence MacIntyre wrote: > > > Uniform MultiPlatform E-IDE driver Revision 6.31 > > ide: assuminmg 33 MHz system bus speed for PIO modes: override with > > idebus=xx > > SIS5513: IDE controller on PCI bus 00 dev 09 > > PCI: Assigned IRQ 14 for device 00:01.1 > > SIS5513: chipset revision 208 > > SIS5513: not 100% native mode: will probe irqs later > > SIS5597 > > ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio > > ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio > > hda: Maxtor 90640D4, ATA DISK drive > > hdc: CD-ROM CDU55E, ATAPI CD/DVD-ROM drive > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > ide1 at 0x170-0x177,0x376 on irq 15 > > > > At this point, the machine hangs... > > interesting, I see the same thing except it hangs not before the disk > drives are initialized but afterwards, when initializing the CD-ROM > drives. (Compiling ide-cd as module permits successful boot but hangs > on insmod). This is with SiS5513 rev 208 IDE function from SiS5591 > chipset with CONFIG_BLK_DEV_SIS5513 and autotune enabled (default). I have this exact same chip on my board (a PCChips M599-LMR or something like that) which works flawlessly on 2.4.2, even with UDMA66. -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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: IDE on 2.4.2
On Sun, Mar 11, 2001 at 10:03:48PM +0100, Martin Diehl wrote: On Fri, 9 Mar 2001, Lawrence MacIntyre wrote: Uniform MultiPlatform E-IDE driver Revision 6.31 ide: assuminmg 33 MHz system bus speed for PIO modes: override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 09 PCI: Assigned IRQ 14 for device 00:01.1 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SIS5597 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio hda: Maxtor 90640D4, ATA DISK drive hdc: CD-ROM CDU55E, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 At this point, the machine hangs... interesting, I see the same thing except it hangs not before the disk drives are initialized but afterwards, when initializing the CD-ROM drives. (Compiling ide-cd as module permits successful boot but hangs on insmod). This is with SiS5513 rev 208 IDE function from SiS5591 chipset with CONFIG_BLK_DEV_SIS5513 and autotune enabled (default). I have this exact same chip on my board (a PCChips M599-LMR or something like that) which works flawlessly on 2.4.2, even with UDMA66. -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
2.4.2 broke gcd (or, audio CD's won't play)
After upgrading to 2.4.2, gcd or any audio CD player will work. The attached chunk of dmesg is the messages produced by attempting to play them. The player just loops through all tracks, playing nothing. Ripping CD's a la cdparanoia still works. If its any consequence, my CD-ROM is now detected as a CD-ROM/DVD-ROM. Is this also a problem, or merely an optimization in the boot-detection routines? Thanks -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
2.4.2 broke gcd (or, audio CD's won't play)
After upgrading to 2.4.2, gcd or any audio CD player will work. The attached chunk of dmesg is the messages produced by attempting to play them. The player just loops through all tracks, playing nothing. Ripping CD's a la cdparanoia still works. If its any consequence, my CD-ROM is now detected as a CD-ROM/DVD-ROM. Is this also a problem, or merely an optimization in the boot-detection routines? Thanks -- -Steven Never ask a geek why, just nod your head and slowly back away. - 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/
