Re: Linux 2.4.5-ac9
In article <002e01c0eead$03c6d890$[EMAIL PROTECTED]> you wrote: >> 2.4.5-ac9 >> o Fix xircom_cb problems with some cisco kit (Ion Badulescu) > One other note, the version in 2.4.4-ac11 is listed as 1.33 while the > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > significant problems with the newer version? The 1.33 sure seems to work > better for me. It went backwards because I switched from my local CVS repository to the tulip driver one. I appologize for the driver not working as well as expected, and will try to find a way to make it work for everyone . Greetings, Arjan van de Ven - 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: Linux 2.4.5-ac9
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler <[EMAIL PROTECTED]> wrote: >> 2.4.5-ac9 > >> o Fix xircom_cb problems with some cisco kit (Ion Badulescu) > > I'm not sure what this is supposed to fix, but it makes my Xircom > RBEM56G-100 almost useless on my network at the office. Actually, I can't > quite blame just this patch, it only makes the problem worse, the driver > from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely > works at all, it seems to think the link is not there, at least not enough > to pull an IP address. The patch does only one thing: it instructs the card not to negotiate full-duplex modes, because (for undocumented and yet unexplained reasons) full-duplex modes don't work well on this card. If you had problems before, then their cause is most likely elsewhere. 1-second ping time is definitely wrong. > The last driver that worked moderately well for me was the one from > 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything > worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco > 6509. I must admist that I haven't tested every version in between. The thing is, I don't really see any significant differences between the 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, some power management stuff, and the half-duplex stuff. None of them should affect the core functionality directly.. Please do me a favor: comment out the call to set_half_duplex() (in xircom_up), recompile and see if it makes a difference. > One other note, the version in 2.4.4-ac11 is listed as 1.33 while the > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > significant problems with the newer version? The 1.33 sure seems to work > better for me. The CVS version is almost irrelevant, I guess Arjan simply rebuild his repository. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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: Linux 2.4.5-ac9
> 2.4.5-ac9 > o Fix xircom_cb problems with some cisco kit (Ion Badulescu) I'm not sure what this is supposed to fix, but it makes my Xircom RBEM56G-100 almost useless on my network at the office. Actually, I can't quite blame just this patch, it only makes the problem worse, the driver from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely works at all, it seems to think the link is not there, at least not enough to pull an IP address. The last driver that worked moderately well for me was the one from 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco 6509. I must admist that I haven't tested every version in between. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. Later, Tom - 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: Linux 2.4.5-ac9
I've just tried the orinoco_cs driver with my "Orinoco Gold" pcmcia card in hopes that I could use this instead of having to rebuild the pcmcia-cs package everytime I try a new kernel... I am seeing the following messages: NETDEV WATCHDOG: eth1: transmit timed out eth1: Tx timeout! Resetting card. and: hermes_read_ltv(): rid (0xfc28) does not match type (0xfc27) hermes_read_ltv(): rid (0xfd10) does not match type (0xfc28) hermes_read_ltv(): rid (0xfd20) does not match type (0xfd10) hermes_read_ltv(): rid (0xfd41) does not match type (0xfd20) hermes_read_ltv(): rid (0xfd42) does not match type (0xfd41) hermes_read_ltv(): rid (0xfd43) does not match type (0xfd42) hermes_read_ltv(): rid (0xfd44) does not match type (0xfd43) hermes_read_ltv(): rid (0xfd4f) does not match type (0xfd44) hermes_read_ltv(): rid (0xfdc1) does not match type (0xfd4f) hermes_read_ltv(): rid (0xfdc6) does not match type (0xfdc1) any ideas? [liebman@xyzzy kernel]$ cat /proc/hermes/eth1/recs PORTTYPE(0xfc00): length=2 (2 bytes)value=0001 MACADDR (0xfc01): length=4 (6 bytes)value=00:02:2D:1B:5C:7E DESIRED_SSID(0xfc02): length=18 (34 bytes) value="xyzzy" CHANNEL (0xfc03): length=2 (2 bytes)value= OWN_SSID(0xfc04): length=18 (34 bytes) value="non-specified SSID !!" SYSTEM_SCALE(0xfc06): length=2 (2 bytes)value=0001 MAX_DATA_LEN(0xfc07): length=2 (2 bytes)value=0900 PM_ENABLE (0xfc09): length=2 (2 bytes)value= PM_MCAST_RX (0xfc0b): length=2 (2 bytes)value=0001 PM_PERIOD (0xfc0c): length=2 (2 bytes)value=0064 NICKNAME(0xfc0e): length=18 (34 bytes) value="xyzzy.zod.com" WEP_ON (0xfc20): length=2 (2 bytes)value=0001 MWO_ROBUST (0xfc25): length=2 (2 bytes)value= MULTICAST_LIST (0xfc80): length=4 (6 bytes)value=01:00:5E:00:00:01 CREATEIBSS (0xfc81): length=2 (2 bytes)value=0001 FRAG_THRESH (0xfc82): length=0 (-2 bytes) value RTS_THRESH (0xfc83): length=2 (2 bytes)value=092B TX_RATE_CTRL(0xfc84): length=2 (2 bytes)value=0003 PROMISCUOUS (0xfc85): length=2 (2 bytes)value= KEYS(0xfcb0): length=0 (-2 bytes) value TX_KEY (0xfcb1): length=2 (2 bytes)value= TICKTIME(0xfce0): length=2 (2 bytes)value=000A PRISM2_TX_KEY (0xfc23): length=2 (2 bytes)value=0002 PRISM2_KEY0 (0xfc24): length=0 (-2 bytes) value PRISM2_KEY1 (0xfc25): length=2 (2 bytes)value=00:00 PRISM2_KEY2 (0xfc26): length=0 (-2 bytes) value PRISM2_KEY3 (0xfc27): length=0 (-2 bytes) value PRISM2_WEP_ON (0xfc28): length=0 (-2 bytes) value CHANNEL_LIST(0xfd10): length=2 (2 bytes)value=07FF STAIDENTITY (0xfd20): length=5 (8 bytes)value=001F-0001-0006-0010 CURRENT_SSID(0xfd41): length=18 (34 bytes) value="xyzzy" CURRENT_BSSID (0xfd42): length=4 (6 bytes)value=02:02:2D:06:30:06 COMMSQUALITY(0xfd43): length=4 (6 bytes)value=-001B-001B CURRENT_TX_RATE (0xfd44): length=2 (2 bytes)value=0002 WEP_AVAIL (0xfd4f): length=2 (2 bytes)value=0001 CURRENT_CHANNEL (0xfdc1): length=2 (2 bytes)value=0003 DATARATES (0xfdc6): length=6 (10 bytes) value=04:00:02:04:0B:16:00:00:00:00 -- Chris - 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: Linux 2.4.5-ac9
On Wed, Jun 06, 2001 at 01:41:31PM +0200, Thomas Sailer wrote: > Christoph Hellwig schrieb: > > > > In article <[EMAIL PROTECTED]> you wrote: > > > 2.4.5-ac9 > > > > > o Add es1371 sound driver locking (Frank Davis) > > > > It's buggy. The locking in ->read and ->write will give > > double ups when a signal is pending and remove a not added waitq > > when programming the dmabuf fails. > > But Alan added a different patch than yours, Mine got _that_ right. > that doesn't seem to have poll in the guard. > > Also, both your and Frank Davis' patch don't care about dac, which > seems bogus to me. Yepp. -- Of course it doesn't work. We've performed a software upgrade. - 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: Linux 2.4.5-ac9
Christoph Hellwig schrieb: > > In article <[EMAIL PROTECTED]> you wrote: > > 2.4.5-ac9 > > > o Add es1371 sound driver locking (Frank Davis) > > It's buggy. The locking in ->read and ->write will give > double ups when a signal is pending and remove a not added waitq > when programming the dmabuf fails. But Alan added a different patch than yours, that doesn't seem to have poll in the guard. Also, both your and Frank Davis' patch don't care about dac, which seems bogus to me. Tom - 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: Linux 2.4.5-ac9
In article <[EMAIL PROTECTED]> you wrote: > 2.4.5-ac9 > o Add es1371 sound driver locking (Frank Davis) It's buggy. The locking in ->read and ->write will give double ups when a signal is pending and remove a not added waitq when programming the dmabuf fails. Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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: Linux 2.4.5-ac9
Alan Cox schrieb: > 2.4.5-ac9 > o Add es1371 sound driver locking (Frank Davis) Looks bogus. Independent processes can open the same device once for reading and once for writing, now you are serializing needlessly these processes. Please revert. Tom - 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: Linux 2.4.5-ac9
Alan Cox schrieb: 2.4.5-ac9 o Add es1371 sound driver locking (Frank Davis) Looks bogus. Independent processes can open the same device once for reading and once for writing, now you are serializing needlessly these processes. Please revert. Tom - 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: Linux 2.4.5-ac9
In article [EMAIL PROTECTED] you wrote: 2.4.5-ac9 o Add es1371 sound driver locking (Frank Davis) It's buggy. The locking in -read and -write will give double ups when a signal is pending and remove a not added waitq when programming the dmabuf fails. Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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: Linux 2.4.5-ac9
Christoph Hellwig schrieb: In article [EMAIL PROTECTED] you wrote: 2.4.5-ac9 o Add es1371 sound driver locking (Frank Davis) It's buggy. The locking in -read and -write will give double ups when a signal is pending and remove a not added waitq when programming the dmabuf fails. But Alan added a different patch than yours, that doesn't seem to have poll in the guard. Also, both your and Frank Davis' patch don't care about dac, which seems bogus to me. Tom - 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: Linux 2.4.5-ac9
On Wed, Jun 06, 2001 at 01:41:31PM +0200, Thomas Sailer wrote: Christoph Hellwig schrieb: In article [EMAIL PROTECTED] you wrote: 2.4.5-ac9 o Add es1371 sound driver locking (Frank Davis) It's buggy. The locking in -read and -write will give double ups when a signal is pending and remove a not added waitq when programming the dmabuf fails. But Alan added a different patch than yours, Mine got _that_ right. that doesn't seem to have poll in the guard. Also, both your and Frank Davis' patch don't care about dac, which seems bogus to me. Yepp. -- Of course it doesn't work. We've performed a software upgrade. - 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: Linux 2.4.5-ac9
I've just tried the orinoco_cs driver with my Orinoco Gold pcmcia card in hopes that I could use this instead of having to rebuild the pcmcia-cs package everytime I try a new kernel... I am seeing the following messages: NETDEV WATCHDOG: eth1: transmit timed out eth1: Tx timeout! Resetting card. and: hermes_read_ltv(): rid (0xfc28) does not match type (0xfc27) hermes_read_ltv(): rid (0xfd10) does not match type (0xfc28) hermes_read_ltv(): rid (0xfd20) does not match type (0xfd10) hermes_read_ltv(): rid (0xfd41) does not match type (0xfd20) hermes_read_ltv(): rid (0xfd42) does not match type (0xfd41) hermes_read_ltv(): rid (0xfd43) does not match type (0xfd42) hermes_read_ltv(): rid (0xfd44) does not match type (0xfd43) hermes_read_ltv(): rid (0xfd4f) does not match type (0xfd44) hermes_read_ltv(): rid (0xfdc1) does not match type (0xfd4f) hermes_read_ltv(): rid (0xfdc6) does not match type (0xfdc1) any ideas? [liebman@xyzzy kernel]$ cat /proc/hermes/eth1/recs PORTTYPE(0xfc00): length=2 (2 bytes)value=0001 MACADDR (0xfc01): length=4 (6 bytes)value=00:02:2D:1B:5C:7E DESIRED_SSID(0xfc02): length=18 (34 bytes) value=xyzzy CHANNEL (0xfc03): length=2 (2 bytes)value= OWN_SSID(0xfc04): length=18 (34 bytes) value=non-specified SSID !! SYSTEM_SCALE(0xfc06): length=2 (2 bytes)value=0001 MAX_DATA_LEN(0xfc07): length=2 (2 bytes)value=0900 PM_ENABLE (0xfc09): length=2 (2 bytes)value= PM_MCAST_RX (0xfc0b): length=2 (2 bytes)value=0001 PM_PERIOD (0xfc0c): length=2 (2 bytes)value=0064 NICKNAME(0xfc0e): length=18 (34 bytes) value=xyzzy.zod.com WEP_ON (0xfc20): length=2 (2 bytes)value=0001 MWO_ROBUST (0xfc25): length=2 (2 bytes)value= MULTICAST_LIST (0xfc80): length=4 (6 bytes)value=01:00:5E:00:00:01 CREATEIBSS (0xfc81): length=2 (2 bytes)value=0001 FRAG_THRESH (0xfc82): length=0 (-2 bytes) value RTS_THRESH (0xfc83): length=2 (2 bytes)value=092B TX_RATE_CTRL(0xfc84): length=2 (2 bytes)value=0003 PROMISCUOUS (0xfc85): length=2 (2 bytes)value= KEYS(0xfcb0): length=0 (-2 bytes) value TX_KEY (0xfcb1): length=2 (2 bytes)value= TICKTIME(0xfce0): length=2 (2 bytes)value=000A PRISM2_TX_KEY (0xfc23): length=2 (2 bytes)value=0002 PRISM2_KEY0 (0xfc24): length=0 (-2 bytes) value PRISM2_KEY1 (0xfc25): length=2 (2 bytes)value=00:00 PRISM2_KEY2 (0xfc26): length=0 (-2 bytes) value PRISM2_KEY3 (0xfc27): length=0 (-2 bytes) value PRISM2_WEP_ON (0xfc28): length=0 (-2 bytes) value CHANNEL_LIST(0xfd10): length=2 (2 bytes)value=07FF STAIDENTITY (0xfd20): length=5 (8 bytes)value=001F-0001-0006-0010 CURRENT_SSID(0xfd41): length=18 (34 bytes) value=xyzzy CURRENT_BSSID (0xfd42): length=4 (6 bytes)value=02:02:2D:06:30:06 COMMSQUALITY(0xfd43): length=4 (6 bytes)value=-001B-001B CURRENT_TX_RATE (0xfd44): length=2 (2 bytes)value=0002 WEP_AVAIL (0xfd4f): length=2 (2 bytes)value=0001 CURRENT_CHANNEL (0xfdc1): length=2 (2 bytes)value=0003 DATARATES (0xfdc6): length=6 (10 bytes) value=04:00:02:04:0B:16:00:00:00:00 -- Chris - 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: Linux 2.4.5-ac9
2.4.5-ac9 o Fix xircom_cb problems with some cisco kit (Ion Badulescu) I'm not sure what this is supposed to fix, but it makes my Xircom RBEM56G-100 almost useless on my network at the office. Actually, I can't quite blame just this patch, it only makes the problem worse, the driver from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely works at all, it seems to think the link is not there, at least not enough to pull an IP address. The last driver that worked moderately well for me was the one from 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco 6509. I must admist that I haven't tested every version in between. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. Later, Tom - 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: Linux 2.4.5-ac9
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler [EMAIL PROTECTED] wrote: 2.4.5-ac9 o Fix xircom_cb problems with some cisco kit (Ion Badulescu) I'm not sure what this is supposed to fix, but it makes my Xircom RBEM56G-100 almost useless on my network at the office. Actually, I can't quite blame just this patch, it only makes the problem worse, the driver from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely works at all, it seems to think the link is not there, at least not enough to pull an IP address. The patch does only one thing: it instructs the card not to negotiate full-duplex modes, because (for undocumented and yet unexplained reasons) full-duplex modes don't work well on this card. If you had problems before, then their cause is most likely elsewhere. 1-second ping time is definitely wrong. The last driver that worked moderately well for me was the one from 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco 6509. I must admist that I haven't tested every version in between. The thing is, I don't really see any significant differences between the 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, some power management stuff, and the half-duplex stuff. None of them should affect the core functionality directly.. Please do me a favor: comment out the call to set_half_duplex() (in xircom_up), recompile and see if it makes a difference. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. The CVS version is almost irrelevant, I guess Arjan simply rebuild his repository. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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: Linux 2.4.5-ac9
In article 002e01c0eead$03c6d890$[EMAIL PROTECTED] you wrote: 2.4.5-ac9 o Fix xircom_cb problems with some cisco kit (Ion Badulescu) One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. It went backwards because I switched from my local CVS repository to the tulip driver one. I appologize for the driver not working as well as expected, and will try to find a way to make it work for everyone . Greetings, Arjan van de Ven - 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: Linux 2.4.5-ac9
Quite positive it's the right map file. I used -m and specified the exact file. David Jeff Garzik wrote: >David Ford wrote: > >> >>EIP; c01269f9<= >>Trace; c01b1021 >>Trace; c01b1c43 >>Trace; c01b2643 >>Trace; c0137fc0 <__emul_lookup_dentry+a4/fc> >>Trace; c0138871 >>Trace; c0167ccb >>Trace; c012e389 >>Trace; c012e2c2 >> > >This trace looks corrupted to me... are you sure that System.map for the >crashed kernel matches -exactly- with the one ksymoops used to decode >this? It uses /proc/ksyms by default, which is incorrect for most >postmortem ksymoops runs... > >rtl8139_interrupt doesn't call tx_timeout, which doesn't call >read_eeprom, which doesn't call proc_getdata. > - 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: Linux 2.4.5-ac9
David Ford wrote: > >>EIP; c01269f9<= > Trace; c01b1021 > Trace; c01b1c43 > Trace; c01b2643 > Trace; c0137fc0 <__emul_lookup_dentry+a4/fc> > Trace; c0138871 > Trace; c0167ccb > Trace; c012e389 > Trace; c012e2c2 This trace looks corrupted to me... are you sure that System.map for the crashed kernel matches -exactly- with the one ksymoops used to decode this? It uses /proc/ksyms by default, which is incorrect for most postmortem ksymoops runs... rtl8139_interrupt doesn't call tx_timeout, which doesn't call read_eeprom, which doesn't call proc_getdata. -- Jeff Garzik | An expert is one who knows more and more about Building 1024| less and less until he knows absolutely everything MandrakeSoft | about nothing. - 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: Linux 2.4.5-ac9
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001b ebx: c13bf768 ecx: c0345060 edx: 2c76
esi: c0a54000 edi: c0a549aa ebp: c0a549aa esp: c57afe54
ds: 0018 es: 0018 ss: 0018
Process sshd (pid: 3627, stackpage=c57af000)
Stack: c02cab45 04dc 800a c03dc900 c03dc900 1000
0246
c01b1021 0c3c 0007 c03dc900 c01b1c43 000a c03dc900
c03dc900
c13c9e50 000a
c13c9e50
Call Trace: [] [] [] []
[]
[] [] [] [] []
Code: 0f 0b 83 c4 08 89 f6 f6 43 11 04 74 51 b8 a5 c2 0f 17 87 06
>>EIP; c01269f9<=
Trace; c01b1021
Trace; c01b1c43
Trace; c01b2643
Trace; c0137fc0 <__emul_lookup_dentry+a4/fc>
Trace; c0138871
Trace; c0167ccb
Trace; c012e389
Trace; c012e2c2
Trace; c012e5b0
Trace; c0106a93
Code; c01269f9
<_EIP>:
Code; c01269f9<=
0: 0f 0b ud2a <=
Code; c01269fb
2: 83 c4 08 add$0x8,%esp
Code; c01269fe
5: 89 f6 mov%esi,%esi
Code; c0126a00
7: f6 43 11 04 testb $0x4,0x11(%ebx)
Code; c0126a04
b: 74 51 je 5e <_EIP+0x5e> c0126a57
Code; c0126a06
d: b8 a5 c2 0f 17mov$0x170fc2a5,%eax
Code; c0126a0b
12: 87 06 xchg %eax,(%esi)
Alan Cox wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
>Intermediate diffs are available from
> http://www.bzimage.org
>
>In terms of going through the code audit almost all the sound drivers still
>need fixing to lock against format changes during a read/write. Poll creating
>and starting a buffer as write does and also mmap during write, write during
>an mmap.
>
>2.4.5-ac9
>
-
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: Linux 2.4.5-ac9
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[c01269f9]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001b ebx: c13bf768 ecx: c0345060 edx: 2c76
esi: c0a54000 edi: c0a549aa ebp: c0a549aa esp: c57afe54
ds: 0018 es: 0018 ss: 0018
Process sshd (pid: 3627, stackpage=c57af000)
Stack: c02cab45 04dc 800a c03dc900 c03dc900 1000
0246
c01b1021 0c3c 0007 c03dc900 c01b1c43 000a c03dc900
c03dc900
c13c9e50 000a
c13c9e50
Call Trace: [c01b1021] [c01b1c43] [c01b2643] [c0137fc0]
[c0138871]
[c0167ccb] [c012e389] [c012e2c2] [c012e5b0] [c0106a93]
Code: 0f 0b 83 c4 08 89 f6 f6 43 11 04 74 51 b8 a5 c2 0f 17 87 06
EIP; c01269f9 proc_getdata+4d/154 =
Trace; c01b1021 read_eeprom+131/1a8
Trace; c01b1c43 rtl8139_tx_timeout+143/148
Trace; c01b2643 rtl8139_interrupt+5f/170
Trace; c0137fc0 __emul_lookup_dentry+a4/fc
Trace; c0138871 open_namei+4d1/560
Trace; c0167ccb leaf_define_dest_src_infos+1a7/1ac
Trace; c012e389 do_readv_writev+15d/228
Trace; c012e2c2 do_readv_writev+96/228
Trace; c012e5b0 sys_pread+bc/d0
Trace; c0106a93 system_call+23/40
Code; c01269f9 proc_getdata+4d/154
_EIP:
Code; c01269f9 proc_getdata+4d/154 =
0: 0f 0b ud2a =
Code; c01269fb proc_getdata+4f/154
2: 83 c4 08 add$0x8,%esp
Code; c01269fe proc_getdata+52/154
5: 89 f6 mov%esi,%esi
Code; c0126a00 proc_getdata+54/154
7: f6 43 11 04 testb $0x4,0x11(%ebx)
Code; c0126a04 proc_getdata+58/154
b: 74 51 je 5e _EIP+0x5e c0126a57
proc_getdata+ab/154
Code; c0126a06 proc_getdata+5a/154
d: b8 a5 c2 0f 17mov$0x170fc2a5,%eax
Code; c0126a0b proc_getdata+5f/154
12: 87 06 xchg %eax,(%esi)
Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
In terms of going through the code audit almost all the sound drivers still
need fixing to lock against format changes during a read/write. Poll creating
and starting a buffer as write does and also mmap during write, write during
an mmap.
2.4.5-ac9
-
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: Linux 2.4.5-ac9
David Ford wrote: EIP; c01269f9 proc_getdata+4d/154 = Trace; c01b1021 read_eeprom+131/1a8 Trace; c01b1c43 rtl8139_tx_timeout+143/148 Trace; c01b2643 rtl8139_interrupt+5f/170 Trace; c0137fc0 __emul_lookup_dentry+a4/fc Trace; c0138871 open_namei+4d1/560 Trace; c0167ccb leaf_define_dest_src_infos+1a7/1ac Trace; c012e389 do_readv_writev+15d/228 Trace; c012e2c2 do_readv_writev+96/228 This trace looks corrupted to me... are you sure that System.map for the crashed kernel matches -exactly- with the one ksymoops used to decode this? It uses /proc/ksyms by default, which is incorrect for most postmortem ksymoops runs... rtl8139_interrupt doesn't call tx_timeout, which doesn't call read_eeprom, which doesn't call proc_getdata. -- Jeff Garzik | An expert is one who knows more and more about Building 1024| less and less until he knows absolutely everything MandrakeSoft | about nothing. - 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: Linux 2.4.5-ac9
Quite positive it's the right map file. I used -m and specified the exact file. David Jeff Garzik wrote: David Ford wrote: EIP; c01269f9 proc_getdata+4d/154 = Trace; c01b1021 read_eeprom+131/1a8 Trace; c01b1c43 rtl8139_tx_timeout+143/148 Trace; c01b2643 rtl8139_interrupt+5f/170 Trace; c0137fc0 __emul_lookup_dentry+a4/fc Trace; c0138871 open_namei+4d1/560 Trace; c0167ccb leaf_define_dest_src_infos+1a7/1ac Trace; c012e389 do_readv_writev+15d/228 Trace; c012e2c2 do_readv_writev+96/228 This trace looks corrupted to me... are you sure that System.map for the crashed kernel matches -exactly- with the one ksymoops used to decode this? It uses /proc/ksyms by default, which is incorrect for most postmortem ksymoops runs... rtl8139_interrupt doesn't call tx_timeout, which doesn't call read_eeprom, which doesn't call proc_getdata. - 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/
