Menu
▾
▴
linux-atm-general — General discussion of ATM networking under linux
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(25) |
Oct
(110) |
Nov
(138) |
Dec
(146) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(221) |
Feb
(154) |
Mar
(113) |
Apr
(84) |
May
(79) |
Jun
(114) |
Jul
(148) |
Aug
(197) |
Sep
(76) |
Oct
(116) |
Nov
(88) |
Dec
(58) |
| 2002 |
Jan
(69) |
Feb
(77) |
Mar
(41) |
Apr
(52) |
May
(80) |
Jun
(129) |
Jul
(54) |
Aug
(38) |
Sep
(50) |
Oct
(69) |
Nov
(39) |
Dec
(59) |
| 2003 |
Jan
(42) |
Feb
(67) |
Mar
(82) |
Apr
(87) |
May
(38) |
Jun
(74) |
Jul
(56) |
Aug
(99) |
Sep
(201) |
Oct
(73) |
Nov
(15) |
Dec
(55) |
| 2004 |
Jan
(67) |
Feb
(54) |
Mar
(73) |
Apr
(67) |
May
(13) |
Jun
(33) |
Jul
(35) |
Aug
(18) |
Sep
(11) |
Oct
(18) |
Nov
(8) |
Dec
(21) |
| 2005 |
Jan
(66) |
Feb
(20) |
Mar
(26) |
Apr
(56) |
May
(39) |
Jun
(16) |
Jul
(21) |
Aug
(32) |
Sep
(33) |
Oct
(55) |
Nov
(126) |
Dec
(8) |
| 2006 |
Jan
(7) |
Feb
(11) |
Mar
|
Apr
(15) |
May
(17) |
Jun
(4) |
Jul
(7) |
Aug
(12) |
Sep
(18) |
Oct
(30) |
Nov
(12) |
Dec
(12) |
| 2007 |
Jan
(6) |
Feb
(20) |
Mar
(16) |
Apr
(20) |
May
(14) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
(17) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2008 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(17) |
Jul
(32) |
Aug
(8) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
| 2009 |
Jan
|
Feb
(12) |
Mar
(10) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(11) |
Sep
(6) |
Oct
(6) |
Nov
(5) |
Dec
|
| 2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
(7) |
Jun
(14) |
Jul
(60) |
Aug
(39) |
Sep
(41) |
Oct
(4) |
Nov
|
Dec
(29) |
| 2011 |
Jan
(15) |
Feb
(3) |
Mar
(37) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(15) |
Aug
(16) |
Sep
|
Oct
(7) |
Nov
(10) |
Dec
(2) |
| 2012 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
| 2015 |
Jan
(6) |
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Philip P. <phi...@re...> - 2010-12-20 19:33:35
|
A few issues... seems to ignore DESTDIR and hence not be cross-compilation friendly: Making install in config make[3]: Entering directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/config' make[4]: Entering directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/config' cp hosts.atm /etc cp: cannot create regular file `/etc/hosts.atm': Permission denied make[4]: [install-exec-local] Error 1 (ignored) test -z "/etc" || /bin/mkdir -p "/home/philipp/kernel2/build_i586/root/etc" /usr/bin/install -c -m 644 hosts.atm '/home/philipp/kernel2/build_i586/root/etc' ... make[3]: Entering directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make install-am make[4]: Entering directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make[5]: Entering directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make install-exec-hook make[6]: Entering directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' /usr/bin/install -c -m 644 ./pca200e.bin /lib/firmware /usr/bin/install: cannot create regular file `/lib/firmware/pca200e.bin': Permission denied make[6]: *** [install-exec-hook] Error 1 make[6]: Leaving directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make[5]: *** [install-exec-am] Error 2 make[5]: Leaving directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make[4]: *** [install-am] Error 2 make[4]: Leaving directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make[3]: *** [install] Error 2 make[3]: Leaving directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src/extra' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2/src' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/philipp/kernel2/build_i586/linux-atm-V2_5_2' make: *** [/home/philipp/kernel2/build_i586/root/usr/sbin/atmsigd] Error 2 On 12/20/10 7:23 AM, chas williams - CONTRACTOR wrote: > can you checkout the V2_5_2 branch and see if it works for you? if > you dont see any problem like this, i will make a release of that > branch this week. > > On Sun, 19 Dec 2010 20:14:28 -0800 > Philip Prindeville<phi...@re...> wrote: > >> 2.5.1 has now been out over a year. >> >> Noticed that there are some issues w/ building this version, >> especially in cross-compilation environments. >> >> ... >> Running libtoolize... >> libtoolize: putting auxiliary files in `.'. >> libtoolize: copying file `./ltmain.sh' >> libtoolize: You should add the contents of the following files to >> `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' >> libtoolize: `/usr/share/aclocal/ltoptions.m4' >> libtoolize: `/usr/share/aclocal/ltversion.m4' >> libtoolize: `/usr/share/aclocal/ltsugar.m4' >> libtoolize: `/usr/share/aclocal/lt~obsolete.m4' >> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to >> configure.in and libtoolize: rerunning libtoolize, to keep the >> correct libtool macros in-tree. libtoolize: Consider adding `-I m4' >> to ACLOCAL_AMFLAGS in Makefile.am. Running aclocal... >> Running autoconf... >> Running autoheader... >> Running automake... >> src/q2931/Makefile.am:21: shell $(CC: non-POSIX variable name >> src/q2931/Makefile.am:21: (probably a GNU make extension) >> src/qgen/Makefile.am:8: `CFLAGS' is a user variable, you should not >> override it; src/qgen/Makefile.am:8: use `AM_CFLAGS' instead. >> Finished... Now run './configure' and 'make'... >> ... >> >> The first warning comes from: >> >> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E >> $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk) >> >> >> and the second warning from: >> >> CFLAGS = @CFLAGS_FOR_BUILD@ >> >> >> Could we do a little cleanup on it and release 2.5.2? >> >> Thanks, >> >> -Philip >> |
|
From: Philip P. <phi...@re...> - 2010-12-20 19:17:56
|
Seems to be the same issue: src/q2931/Makefile.am:21: shell $(CC: non-POSIX variable name src/q2931/Makefile.am:21: (probably a GNU make extension) src/qgen/Makefile.am:8: `CFLAGS' is a user variable, you should not override it; src/qgen/Makefile.am:8: use `AM_CFLAGS' instead. Let me see if there's a simple fix from the automake folks. On 12/20/10 7:23 AM, chas williams - CONTRACTOR wrote: > can you checkout the V2_5_2 branch and see if it works for you? if > you dont see any problem like this, i will make a release of that > branch this week. > > On Sun, 19 Dec 2010 20:14:28 -0800 > Philip Prindeville<phi...@re...> wrote: > >> 2.5.1 has now been out over a year. >> >> Noticed that there are some issues w/ building this version, >> especially in cross-compilation environments. >> >> ... >> Running libtoolize... >> libtoolize: putting auxiliary files in `.'. >> libtoolize: copying file `./ltmain.sh' >> libtoolize: You should add the contents of the following files to >> `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' >> libtoolize: `/usr/share/aclocal/ltoptions.m4' >> libtoolize: `/usr/share/aclocal/ltversion.m4' >> libtoolize: `/usr/share/aclocal/ltsugar.m4' >> libtoolize: `/usr/share/aclocal/lt~obsolete.m4' >> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to >> configure.in and libtoolize: rerunning libtoolize, to keep the >> correct libtool macros in-tree. libtoolize: Consider adding `-I m4' >> to ACLOCAL_AMFLAGS in Makefile.am. Running aclocal... >> Running autoconf... >> Running autoheader... >> Running automake... >> src/q2931/Makefile.am:21: shell $(CC: non-POSIX variable name >> src/q2931/Makefile.am:21: (probably a GNU make extension) >> src/qgen/Makefile.am:8: `CFLAGS' is a user variable, you should not >> override it; src/qgen/Makefile.am:8: use `AM_CFLAGS' instead. >> Finished... Now run './configure' and 'make'... >> ... >> >> The first warning comes from: >> >> SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E >> $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk) >> >> >> and the second warning from: >> >> CFLAGS = @CFLAGS_FOR_BUILD@ >> >> >> Could we do a little cleanup on it and release 2.5.2? >> >> Thanks, >> >> -Philip |
|
From: chas w. - C. <ch...@cm...> - 2010-12-20 15:24:31
|
can you checkout the V2_5_2 branch and see if it works for you? if you dont see any problem like this, i will make a release of that branch this week. On Sun, 19 Dec 2010 20:14:28 -0800 Philip Prindeville <phi...@re...> wrote: > 2.5.1 has now been out over a year. > > Noticed that there are some issues w/ building this version, > especially in cross-compilation environments. > > ... > Running libtoolize... > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: You should add the contents of the following files to > `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' > libtoolize: `/usr/share/aclocal/ltoptions.m4' > libtoolize: `/usr/share/aclocal/ltversion.m4' > libtoolize: `/usr/share/aclocal/ltsugar.m4' > libtoolize: `/usr/share/aclocal/lt~obsolete.m4' > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to > configure.in and libtoolize: rerunning libtoolize, to keep the > correct libtool macros in-tree. libtoolize: Consider adding `-I m4' > to ACLOCAL_AMFLAGS in Makefile.am. Running aclocal... > Running autoconf... > Running autoheader... > Running automake... > src/q2931/Makefile.am:21: shell $(CC: non-POSIX variable name > src/q2931/Makefile.am:21: (probably a GNU make extension) > src/qgen/Makefile.am:8: `CFLAGS' is a user variable, you should not > override it; src/qgen/Makefile.am:8: use `AM_CFLAGS' instead. > Finished... Now run './configure' and 'make'... > ... > > The first warning comes from: > > SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E > $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk) > > > and the second warning from: > > CFLAGS = @CFLAGS_FOR_BUILD@ > > > Could we do a little cleanup on it and release 2.5.2? > > Thanks, > > -Philip > > > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > |
|
From: Philip P. <phi...@re...> - 2010-12-20 04:14:45
|
2.5.1 has now been out over a year. Noticed that there are some issues w/ building this version, especially in cross-compilation environments. ... Running libtoolize... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' libtoolize: `/usr/share/aclocal/ltoptions.m4' libtoolize: `/usr/share/aclocal/ltversion.m4' libtoolize: `/usr/share/aclocal/ltsugar.m4' libtoolize: `/usr/share/aclocal/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. Running aclocal... Running autoconf... Running autoheader... Running automake... src/q2931/Makefile.am:21: shell $(CC: non-POSIX variable name src/q2931/Makefile.am:21: (probably a GNU make extension) src/qgen/Makefile.am:8: `CFLAGS' is a user variable, you should not override it; src/qgen/Makefile.am:8: use `AM_CFLAGS' instead. Finished... Now run './configure' and 'make'... ... The first warning comes from: SYMFILES = $(srcdir)/uni.h $(shell $(CC) $(CFLAGS) -E $(srcdir)/header.c | $(AWK) -f $(srcdir)/script.awk) and the second warning from: CFLAGS = @CFLAGS_FOR_BUILD@ Could we do a little cleanup on it and release 2.5.2? Thanks, -Philip |
|
From: chas w. - C. <ch...@cm...> - 2010-12-14 12:34:25
|
On Tue, 07 Dec 2010 12:45:53 -0800 Philip Prindeville <phi...@re...> wrote: > Yeah, I brought up using netdev's a month or so ago, but it wasn't > warmly received. you wanted to put atm pdu's into the network stack (so you can watch them with tcpdump) -- atleast i think you asked about that. you cant push 'packets' to be examined by tcpdump without having a netdev interface (atleast i dont think you can). > I have no problem with it appearing in the output of 'ifconfig'. i bothers me a little bit. people are going to try to ifconfig interfaces on it and then wonder why it doesnt work. i would just prefer that the parent interfaces stay invisible. > People use Ethernet interfaces in a purely VLAN environment, without > being confused by the presence of the 'naked' Ethernet interface, so > I think it's a red herring. maybe. i still think we can implement netlink without netdevs. like i said i am of two minds about the problem. > It was suggested that using netdev's would also effect the data path, > though I have to say I don't understand why this would be so. netdevs dont have to affect the data path. only if we decide to push the atm pdus through the network queues. as of now, when an ethernet card finishes receiving a packet, it pushes the packet onto a queue to be processed by someone/something else that was subscribed to the queue. this has a couple of side effects -- a small delay but decoupling between the parts of the network stack which makes it easier to write things. the atm stack pushes pdus directly to the protocol (aal5 sockets, lec, clip). this means the protocol handlers must be interrupt safe and capable of running in any context that the atm drivers choose to deliver pdus. |
|
From: Philip P. <phi...@re...> - 2010-12-12 19:12:44
|
On 12/7/10 12:37 PM, chas williams - CONTRACTOR wrote: > On Sun, 05 Dec 2010 12:39:56 -0800 > Philip Prindeville<phi...@re...> wrote: > >> Hi. >> >> I was thinking about how the kernel assigns IfIndex numbers for >> (amongst other things) SNMP to interfaces, and the fact that ATM >> doesn't use netdev's means that it can't be given one that's >> meaningful. >> >> It also can't be the source or sync for netlink messages >> (route/link.h). >> >> How could the ATM infrastructure be modified to better integrate with >> the kernel's notion of what an 'interface' is? > at one point there was talking about convering atm_device to use a > net_device instead. this would have fixed a couple of problems at once: > the device registration/allocation races, shutdown/removal races, > duplication of code, et al. the big drawback might be that raw atm > devices would appear if the output of ifconfig which might be confusing. > > atm isnt alone in this. infiniband maintains is own private device > structure and registration code. so conversion might not be necessary. > > as far as netlink, i think we just need to define a netlink family > for atm devices and them create the necessary routines to generate > and handle these messages. go through the archives. there was some > talk about this too at one point. What's the downside of using net_device's? -Philip |
|
From: chas w. - C. <ch...@cm...> - 2010-12-07 20:59:28
|
On Sun, 05 Dec 2010 12:39:56 -0800 Philip Prindeville <phi...@re...> wrote: > Hi. > > I was thinking about how the kernel assigns IfIndex numbers for > (amongst other things) SNMP to interfaces, and the fact that ATM > doesn't use netdev's means that it can't be given one that's > meaningful. > > It also can't be the source or sync for netlink messages > (route/link.h). > > How could the ATM infrastructure be modified to better integrate with > the kernel's notion of what an 'interface' is? at one point there was talking about convering atm_device to use a net_device instead. this would have fixed a couple of problems at once: the device registration/allocation races, shutdown/removal races, duplication of code, et al. the big drawback might be that raw atm devices would appear if the output of ifconfig which might be confusing. atm isnt alone in this. infiniband maintains is own private device structure and registration code. so conversion might not be necessary. as far as netlink, i think we just need to define a netlink family for atm devices and them create the necessary routines to generate and handle these messages. go through the archives. there was some talk about this too at one point. |
|
From: Philip P. <phi...@re...> - 2010-12-07 20:47:21
|
On 12/7/10 12:37 PM, chas williams - CONTRACTOR wrote: > On Sun, 05 Dec 2010 12:39:56 -0800 > Philip Prindeville<phi...@re...> wrote: > >> Hi. >> >> I was thinking about how the kernel assigns IfIndex numbers for >> (amongst other things) SNMP to interfaces, and the fact that ATM >> doesn't use netdev's means that it can't be given one that's >> meaningful. >> >> It also can't be the source or sync for netlink messages >> (route/link.h). >> >> How could the ATM infrastructure be modified to better integrate with >> the kernel's notion of what an 'interface' is? > at one point there was talking about convering atm_device to use a > net_device instead. this would have fixed a couple of problems at once: > the device registration/allocation races, shutdown/removal races, > duplication of code, et al. the big drawback might be that raw atm > devices would appear if the output of ifconfig which might be confusing. > > atm isnt alone in this. infiniband maintains is own private device > structure and registration code. so conversion might not be necessary. > > as far as netlink, i think we just need to define a netlink family > for atm devices and them create the necessary routines to generate > and handle these messages. go through the archives. there was some > talk about this too at one point. Yeah, I brought up using netdev's a month or so ago, but it wasn't warmly received. I have no problem with it appearing in the output of 'ifconfig'. People use Ethernet interfaces in a purely VLAN environment, without being confused by the presence of the 'naked' Ethernet interface, so I think it's a red herring. It was suggested that using netdev's would also effect the data path, though I have to say I don't understand why this would be so. -Philip |
|
From: Philip P. <phi...@re...> - 2010-12-05 20:40:11
|
Hi. I was thinking about how the kernel assigns IfIndex numbers for (amongst other things) SNMP to interfaces, and the fact that ATM doesn't use netdev's means that it can't be given one that's meaningful. It also can't be the source or sync for netlink messages (route/link.h). How could the ATM infrastructure be modified to better integrate with the kernel's notion of what an 'interface' is? Thanks, -Philip |
|
From: Philip P. <phi...@re...> - 2010-10-06 17:45:23
|
On 10/6/10 10:26 AM, Philip Prindeville wrote:
> On 9/23/10 3:22 PM, Karl Hiramoto wrote:
>> On 09/23/10 23:57, Philip Prindeville wrote:
>>> Ok, now I'm seeing:
>>>
>>>>>>> Plugged in and trained up
>>> 10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
>>> pfifo_fast state UNKNOWN qlen 3
>>> link/ppp
>>>
>>>
>>>>>>> Unplugged
>>> 10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
>>> pfifo_fast state UNKNOWN qlen 3
>>> link/ppp
>>>
>>>
>>> Still no difference. And yes, I have the carrier patch for the
>>> solos-pci.c driver.
>> The strange thing is that the printk in pppoatm_dev_event() did not show
>> up, so I'm wondering if the solos-pci driver is calling
>> atm_dev_signal_change() when the line goes up/down.
> Well, it turns out that it isn't. We built a module with lots of pr_info()'s liberally sprinkled, and we see:
>
> card->atmdev[i]->ci_range.vpi_bits = 8;
> card->atmdev[i]->ci_range.vci_bits = 16;
> card->atmdev[i]->dev_data = card;
> card->atmdev[i]->phy_data = (void *)(unsigned long)i;
> pr_info("%s:%d unknown %d\n", __func__, __LINE__, card->atmdev[i]);
> atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);
>
>
>
> being hit inside atm_init(), but not any of the other calls to atm_dev_signal_change().
>
> process_status() calls atm_dev_signal_change() as well, but doesn't get compiled-in unless SolosParameterSysfs is defined, which I really don't understand.
Ok, part of the above is true: process_status() doesn't get compiled unless SolosParameterSysfs() is turned on, but for kernels 2.6.25 it *is* turned on.
So that's not the problem for us. In my case, it seems we're never seeing a PKT_STATUS being indicated.
-Philip
> The card should be handling status updates regardless of whether we're using /sys or not, right?
>
> What am I missing here?
>
> I'm trying to get some optimizations done in PPP at the process-level based on watching carrier state when using the pppoatm and pppoe plugins, but I'm blocked on the card not handling link-state indications properly.
>
>> if you add "#define DEBUG 1" at the top of net/atm/common.c hopefully
>> we should see the pr_debug() in atm_dev_signal_change() show up in the
>> logs. Otherwise the problem is in the solos-pci driver.
> Yup. We have a smoking gun.
>
> Actually, code inspection would have revealed this... if I suspected that enabling the sysfs support would make a basic difference, which didn't seem likely.
>
> -Philip
>
>>> Sep 23 14:52:19 pbx2 user.warn kernel: eth1: Transmit timeout, status
>>> c 2b 484 0
>>> Sep 23 14:52:19 pbx2 user.warn kernel: ------------[ cut here ]------------
>>> Sep 23 14:52:19 pbx2 user.warn kernel: WARNING: at kernel/softirq.c:136
>>> local_bh_enable+0x2f/0x76()
>>> Sep 23 14:52:19 pbx2 user.warn kernel: Modules linked in: binfmt_misc
>>> aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp
>>> nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle
>>> iptable_filter xt_multiport xt_state xt_limit xt_conntrack
>>> Sep 23 14:52:19 pbx2 user.warn kernel: Pid: 0, comm: swapper Tainted:
>>> P W 2.6.27.49-astlinux #1
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01153de>]
>>> warn_on_slowpath+0x40/0x63
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01be378>]
>>> cipher_crypt_unaligned+0x6f/0xa7
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01065e8>] read_tsc+0x6/0x22
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c012899e>]
>>> getnstimeofday+0x4a/0xc7
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01267c2>] ktime_get_ts+0x1d/0x3f
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c012604e>]
>>> hrtimer_forward+0xe2/0xfe
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c014d80e>] free_block+0xb3/0xef
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c02aa0e1>]
>>> __atomic_notifier_call_chain+0x19/0x36
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c011915d>]
>>> local_bh_enable+0x2f/0x76
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e01a8f8a>]
>>> destroy_conntrack+0xb8/0xd7 [nf_conntrack]
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0266262>]
>>> nf_conntrack_destroy+0x1e/0x34
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da41>]
>>> skb_release_all+0x80/0xbd
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da9c>] __kfree_skb+0x8/0x61
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e0017589>]
>>> cp_clean_rings+0xbb/0xf8 [8139cp]
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e0018b58>]
>>> cp_tx_timeout+0x6b/0xca [8139cp]
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c025df4b>] dev_watchdog+0x0/0x176
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c025e051>]
>>> dev_watchdog+0x106/0x176
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e0097f3c>]
>>> coretimer_func+0xb1/0x133 [dahdi]
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c011c052>]
>>> run_timer_softirq+0x116/0x17a
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118cdc>] __do_softirq+0x35/0x75
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118d3e>] do_softirq+0x22/0x26
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118f18>] irq_exit+0x25/0x30
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c010477c>] do_IRQ+0x4d/0x5d
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c010394b>]
>>> common_interrupt+0x23/0x28
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0106f3d>] default_idle+0x25/0x38
>>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c010254b>] cpu_idle+0x37/0x5f
>>> Sep 23 14:52:19 pbx2 user.warn kernel: =======================
>>> Sep 23 14:52:19 pbx2 user.warn kernel: ---[ end trace 4f9198b05afcf39f ]---
>>> Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm push
>>> Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm_send (skb=0xde660c00,
>>> vcc=0xde741800)
>>> Sep 23 14:52:19 pbx2 user.debug kernel:
>> An ugly warning from a tainted kernel that looks like it has nothing to
>> do with the atm stack.
>>
>>> bytes.
>>> Sep 23 14:54:13 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x3
>>> "Peer not responding"]
>>> Sep 23 14:54:13 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80,
>>> vcc=0xde741800)
>>> Sep 23 14:54:13 pbx2 user.debug kernel:
>>> atm_skb(de660a80)->vcc(de741800)->dev(de639000)
>>> Sep 23 14:54:16 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x4
>>> "Peer not responding"]
>>> Sep 23 14:54:16 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a980,
>>> vcc=0xde741800)
>>> Sep 23 14:54:16 pbx2 user.debug kernel:
>>> atm_skb(de74a980)->vcc(de741800)->dev(de639000)
>>> Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Connection terminated.
>>> Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Modem hangup
>>> Sep 23 14:54:19 pbx2 user.debug kernel: pppoatm push
>>> Sep 23 14:54:19 pbx2 user.debug kernel: removing ATMPPP VCC de7752a0
>>>
>
|
|
From: Philip P. <phi...@re...> - 2010-10-06 17:27:46
|
On 9/23/10 3:22 PM, Karl Hiramoto wrote:
> On 09/23/10 23:57, Philip Prindeville wrote:
>> Ok, now I'm seeing:
>>
>>>>>> Plugged in and trained up
>> 10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
>> pfifo_fast state UNKNOWN qlen 3
>> link/ppp
>>
>>
>>>>>> Unplugged
>> 10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
>> pfifo_fast state UNKNOWN qlen 3
>> link/ppp
>>
>>
>> Still no difference. And yes, I have the carrier patch for the
>> solos-pci.c driver.
>
> The strange thing is that the printk in pppoatm_dev_event() did not show
> up, so I'm wondering if the solos-pci driver is calling
> atm_dev_signal_change() when the line goes up/down.
Well, it turns out that it isn't. We built a module with lots of pr_info()'s liberally sprinkled, and we see:
card->atmdev[i]->ci_range.vpi_bits = 8;
card->atmdev[i]->ci_range.vci_bits = 16;
card->atmdev[i]->dev_data = card;
card->atmdev[i]->phy_data = (void *)(unsigned long)i;
pr_info("%s:%d unknown %d\n", __func__, __LINE__, card->atmdev[i]);
atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);
being hit inside atm_init(), but not any of the other calls to atm_dev_signal_change().
process_status() calls atm_dev_signal_change() as well, but doesn't get compiled-in unless SolosParameterSysfs is defined, which I really don't understand.
The card should be handling status updates regardless of whether we're using /sys or not, right?
What am I missing here?
I'm trying to get some optimizations done in PPP at the process-level based on watching carrier state when using the pppoatm and pppoe plugins, but I'm blocked on the card not handling link-state indications properly.
> if you add "#define DEBUG 1" at the top of net/atm/common.c hopefully
> we should see the pr_debug() in atm_dev_signal_change() show up in the
> logs. Otherwise the problem is in the solos-pci driver.
Yup. We have a smoking gun.
Actually, code inspection would have revealed this... if I suspected that enabling the sysfs support would make a basic difference, which didn't seem likely.
-Philip
>
>> Sep 23 14:52:19 pbx2 user.warn kernel: eth1: Transmit timeout, status
>> c 2b 484 0
>> Sep 23 14:52:19 pbx2 user.warn kernel: ------------[ cut here ]------------
>> Sep 23 14:52:19 pbx2 user.warn kernel: WARNING: at kernel/softirq.c:136
>> local_bh_enable+0x2f/0x76()
>> Sep 23 14:52:19 pbx2 user.warn kernel: Modules linked in: binfmt_misc
>> aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp
>> nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle
>> iptable_filter xt_multiport xt_state xt_limit xt_conntrack
>> Sep 23 14:52:19 pbx2 user.warn kernel: Pid: 0, comm: swapper Tainted:
>> P W 2.6.27.49-astlinux #1
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01153de>]
>> warn_on_slowpath+0x40/0x63
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01be378>]
>> cipher_crypt_unaligned+0x6f/0xa7
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01065e8>] read_tsc+0x6/0x22
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c012899e>]
>> getnstimeofday+0x4a/0xc7
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c01267c2>] ktime_get_ts+0x1d/0x3f
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c012604e>]
>> hrtimer_forward+0xe2/0xfe
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c014d80e>] free_block+0xb3/0xef
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c02aa0e1>]
>> __atomic_notifier_call_chain+0x19/0x36
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c011915d>]
>> local_bh_enable+0x2f/0x76
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e01a8f8a>]
>> destroy_conntrack+0xb8/0xd7 [nf_conntrack]
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0266262>]
>> nf_conntrack_destroy+0x1e/0x34
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da41>]
>> skb_release_all+0x80/0xbd
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da9c>] __kfree_skb+0x8/0x61
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e0017589>]
>> cp_clean_rings+0xbb/0xf8 [8139cp]
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e0018b58>]
>> cp_tx_timeout+0x6b/0xca [8139cp]
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c025df4b>] dev_watchdog+0x0/0x176
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c025e051>]
>> dev_watchdog+0x106/0x176
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<e0097f3c>]
>> coretimer_func+0xb1/0x133 [dahdi]
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c011c052>]
>> run_timer_softirq+0x116/0x17a
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118cdc>] __do_softirq+0x35/0x75
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118d3e>] do_softirq+0x22/0x26
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118f18>] irq_exit+0x25/0x30
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c010477c>] do_IRQ+0x4d/0x5d
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c010394b>]
>> common_interrupt+0x23/0x28
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c0106f3d>] default_idle+0x25/0x38
>> Sep 23 14:52:19 pbx2 user.warn kernel: [<c010254b>] cpu_idle+0x37/0x5f
>> Sep 23 14:52:19 pbx2 user.warn kernel: =======================
>> Sep 23 14:52:19 pbx2 user.warn kernel: ---[ end trace 4f9198b05afcf39f ]---
>> Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm push
>> Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm_send (skb=0xde660c00,
>> vcc=0xde741800)
>> Sep 23 14:52:19 pbx2 user.debug kernel:
> An ugly warning from a tainted kernel that looks like it has nothing to
> do with the atm stack.
>
>> bytes.
>> Sep 23 14:54:13 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x3
>> "Peer not responding"]
>> Sep 23 14:54:13 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80,
>> vcc=0xde741800)
>> Sep 23 14:54:13 pbx2 user.debug kernel:
>> atm_skb(de660a80)->vcc(de741800)->dev(de639000)
>> Sep 23 14:54:16 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x4
>> "Peer not responding"]
>> Sep 23 14:54:16 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a980,
>> vcc=0xde741800)
>> Sep 23 14:54:16 pbx2 user.debug kernel:
>> atm_skb(de74a980)->vcc(de741800)->dev(de639000)
>> Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Connection terminated.
>> Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Modem hangup
>> Sep 23 14:54:19 pbx2 user.debug kernel: pppoatm push
>> Sep 23 14:54:19 pbx2 user.debug kernel: removing ATMPPP VCC de7752a0
>>
>
|
|
From: chas w. - C. <ch...@cm...> - 2010-10-04 15:32:49
|
On Sun, 3 Oct 2010 21:51:25 +0200 Karl Hiramoto <ka...@hi...> wrote: > This will be used for device testing carrier signal changes in other > parts of the atm stack. adummy might be a better choice for this. however, i dont know what to about dave's comment concerning no more sysfs knobs. we dont have a general utility for talking to atm drivers. |
|
From: Karl H. <ka...@hi...> - 2010-10-03 19:51:51
|
This will be used for device testing carrier signal changes in other parts of
the atm stack.
Carrier lost set by:
echo -n 0 > /sys/class/atm/atmtcp0/carrier
Carrier detected:
echo -n 1 > /sys/class/atm/atmtcp0/carrier
Signed-off-by: Karl Hiramoto <ka...@hi...>
---
drivers/atm/atmtcp.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/atm/atmtcp.c b/drivers/atm/atmtcp.c
index b910181..7540e33 100644
--- a/drivers/atm/atmtcp.c
+++ b/drivers/atm/atmtcp.c
@@ -210,6 +210,18 @@ static int atmtcp_v_send(struct atm_vcc *vcc,struct sk_buff *skb)
atomic_inc(&vcc->stats->tx_err);
return -ENOLINK;
}
+
+ if (vcc->dev->signal == ATM_PHY_SIG_LOST) {
+ pr_warning(DEV_LABEL ": Dropping TX pkt, upper layer not handling carrier signal lost\n");
+ if (vcc->pop)
+ vcc->pop(vcc, skb);
+ else
+ dev_kfree_skb(skb);
+
+ atomic_inc(&vcc->stats->tx_err);
+ return -ENOLINK;
+ }
+
size = skb->len+sizeof(struct atmtcp_hdr);
new_skb = atm_alloc_charge(out_vcc,size,GFP_ATOMIC);
if (!new_skb) {
@@ -304,6 +316,12 @@ static int atmtcp_c_send(struct atm_vcc *vcc,struct sk_buff *skb)
atomic_inc(&vcc->stats->tx_err);
goto done;
}
+
+ if (out_vcc->dev->signal == ATM_PHY_SIG_LOST) {
+ pr_debug(DEV_LABEL ": Dropping RX pkt while no carrier signal\n");
+ result = -ENOLINK;
+ goto done;
+ }
skb_pull(skb,sizeof(struct atmtcp_hdr));
new_skb = atm_alloc_charge(out_vcc,skb->len,GFP_KERNEL);
if (!new_skb) {
@@ -356,6 +374,43 @@ static struct atm_dev atmtcp_control_dev = {
.lock = __SPIN_LOCK_UNLOCKED(atmtcp_control_dev.lock)
};
+static ssize_t __set_signal(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct atm_dev *atm_dev = container_of(dev, struct atm_dev, class_dev);
+ int signal;
+
+ if (sscanf(buf, "%d", &signal) == 1) {
+
+ if (signal < ATM_PHY_SIG_LOST || signal > ATM_PHY_SIG_FOUND)
+ signal = ATM_PHY_SIG_UNKNOWN;
+
+ atm_dev_signal_change(atm_dev, signal);
+ return 1;
+ }
+ return -EINVAL;
+}
+
+static ssize_t __show_signal(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct atm_dev *atm_dev = container_of(dev, struct atm_dev, class_dev);
+ return sprintf(buf, "%d\n", atm_dev->signal);
+}
+
+static DEVICE_ATTR(signal, 0644, __show_signal, __set_signal);
+
+static struct attribute *atmtcp_attrs[] = {
+ &dev_attr_signal.attr,
+ NULL
+};
+
+static struct attribute_group atmtcp_group_attrs = {
+ .name = NULL, /* We want them in dev's root folder */
+ .attrs = atmtcp_attrs
+};
+
static int atmtcp_create(int itf,int persist,struct atm_dev **result)
{
@@ -376,6 +431,10 @@ static int atmtcp_create(int itf,int persist,struct atm_dev **result)
dev->dev_data = dev_data;
PRIV(dev)->vcc = NULL;
PRIV(dev)->persist = persist;
+
+ if (sysfs_create_group(&dev->class_dev.kobj, &atmtcp_group_attrs))
+ dev_err(&dev->class_dev, "Could not register sysfs attrs for atmtcp\n");
+
if (result) *result = dev;
return 0;
}
--
1.7.2.2
|
|
From: Karl H. <ka...@hi...> - 2010-09-23 22:22:03
|
On 09/23/10 23:57, Philip Prindeville wrote: > Ok, now I'm seeing: > >>>>> Plugged in and trained up > 10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > > >>>>> Unplugged > 10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > > > Still no difference. And yes, I have the carrier patch for the > solos-pci.c driver. The strange thing is that the printk in pppoatm_dev_event() did not show up, so I'm wondering if the solos-pci driver is calling atm_dev_signal_change() when the line goes up/down. if you add "#define DEBUG 1" at the top of net/atm/common.c hopefully we should see the pr_debug() in atm_dev_signal_change() show up in the logs. Otherwise the problem is in the solos-pci driver. > Sep 23 14:52:19 pbx2 user.warn kernel: eth1: Transmit timeout, status > c 2b 484 0 > Sep 23 14:52:19 pbx2 user.warn kernel: ------------[ cut here ]------------ > Sep 23 14:52:19 pbx2 user.warn kernel: WARNING: at kernel/softirq.c:136 > local_bh_enable+0x2f/0x76() > Sep 23 14:52:19 pbx2 user.warn kernel: Modules linked in: binfmt_misc > aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp > nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle > iptable_filter xt_multiport xt_state xt_limit xt_conntrack > Sep 23 14:52:19 pbx2 user.warn kernel: Pid: 0, comm: swapper Tainted: > P W 2.6.27.49-astlinux #1 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c01153de>] > warn_on_slowpath+0x40/0x63 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c01be378>] > cipher_crypt_unaligned+0x6f/0xa7 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c01065e8>] read_tsc+0x6/0x22 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c012899e>] > getnstimeofday+0x4a/0xc7 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c01267c2>] ktime_get_ts+0x1d/0x3f > Sep 23 14:52:19 pbx2 user.warn kernel: [<c012604e>] > hrtimer_forward+0xe2/0xfe > Sep 23 14:52:19 pbx2 user.warn kernel: [<c014d80e>] free_block+0xb3/0xef > Sep 23 14:52:19 pbx2 user.warn kernel: [<c02aa0e1>] > __atomic_notifier_call_chain+0x19/0x36 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c011915d>] > local_bh_enable+0x2f/0x76 > Sep 23 14:52:19 pbx2 user.warn kernel: [<e01a8f8a>] > destroy_conntrack+0xb8/0xd7 [nf_conntrack] > Sep 23 14:52:19 pbx2 user.warn kernel: [<c0266262>] > nf_conntrack_destroy+0x1e/0x34 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da41>] > skb_release_all+0x80/0xbd > Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da9c>] __kfree_skb+0x8/0x61 > Sep 23 14:52:19 pbx2 user.warn kernel: [<e0017589>] > cp_clean_rings+0xbb/0xf8 [8139cp] > Sep 23 14:52:19 pbx2 user.warn kernel: [<e0018b58>] > cp_tx_timeout+0x6b/0xca [8139cp] > Sep 23 14:52:19 pbx2 user.warn kernel: [<c025df4b>] dev_watchdog+0x0/0x176 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c025e051>] > dev_watchdog+0x106/0x176 > Sep 23 14:52:19 pbx2 user.warn kernel: [<e0097f3c>] > coretimer_func+0xb1/0x133 [dahdi] > Sep 23 14:52:19 pbx2 user.warn kernel: [<c011c052>] > run_timer_softirq+0x116/0x17a > Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118cdc>] __do_softirq+0x35/0x75 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118d3e>] do_softirq+0x22/0x26 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118f18>] irq_exit+0x25/0x30 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c010477c>] do_IRQ+0x4d/0x5d > Sep 23 14:52:19 pbx2 user.warn kernel: [<c010394b>] > common_interrupt+0x23/0x28 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c0106f3d>] default_idle+0x25/0x38 > Sep 23 14:52:19 pbx2 user.warn kernel: [<c010254b>] cpu_idle+0x37/0x5f > Sep 23 14:52:19 pbx2 user.warn kernel: ======================= > Sep 23 14:52:19 pbx2 user.warn kernel: ---[ end trace 4f9198b05afcf39f ]--- > Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm push > Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm_send (skb=0xde660c00, > vcc=0xde741800) > Sep 23 14:52:19 pbx2 user.debug kernel: An ugly warning from a tainted kernel that looks like it has nothing to do with the atm stack. > bytes. > Sep 23 14:54:13 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x3 > "Peer not responding"] > Sep 23 14:54:13 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80, > vcc=0xde741800) > Sep 23 14:54:13 pbx2 user.debug kernel: > atm_skb(de660a80)->vcc(de741800)->dev(de639000) > Sep 23 14:54:16 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x4 > "Peer not responding"] > Sep 23 14:54:16 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a980, > vcc=0xde741800) > Sep 23 14:54:16 pbx2 user.debug kernel: > atm_skb(de74a980)->vcc(de741800)->dev(de639000) > Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Connection terminated. > Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Modem hangup > Sep 23 14:54:19 pbx2 user.debug kernel: pppoatm push > Sep 23 14:54:19 pbx2 user.debug kernel: removing ATMPPP VCC de7752a0 > |
|
From: Philip P. <phi...@re...> - 2010-09-23 21:59:01
|
On 9/23/10 12:18 PM, Karl Hiramoto wrote: > On 09/23/10 21:00, Philip Prindeville wrote: >> Note that I'm building the solos driver from "openadsl" on sourceforge >> (since I'm running 2.6.27.49), not whatever is currently in 2.6.33 or >> 2.6.35 stable. >> > It wont' work with that version unless it's patched with the > atm_dev_signal_change() call. It's only a 3 line change but needs to > be the same as this patch: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f > > > > Thanks. > > Karl Yup, got that. |
|
From: Philip P. <phi...@re...> - 2010-09-23 21:58:40
|
On 9/23/10 10:47 AM, Karl Hiramoto wrote:
> New patch attached that should fix the "scheduling while atomic". I also
> added a bunch of debug printk's so we can hopefully figure out what is
> happening. Send the dmesg output when un/plugging the cable. I
> assume the solos-pci driver does this well and calls
> atm_dev_signal_change().
>
> --
> Karl
>
>
Ok, now I'm seeing:
>>>> Plugged in and trained up
10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
>>>> Unplugged
10: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
Still no difference. And yes, I have the carrier patch for the solos-pci.c driver.
Here's the contents of my logging:
Sep 23 14:46:18 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:18 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8ce0, vcc=0xde741800)
Sep 23 14:46:18 pbx2 user.debug kernel: atm_skb(df2b8ce0)->vcc(de741800)->dev(de639000)
Sep 23 14:46:28 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:28 pbx2 user.debug kernel: pppoatm_send (skb=0xcb10ac20, vcc=0xde741800)
Sep 23 14:46:28 pbx2 user.debug kernel: atm_skb(cb10ac20)->vcc(de741800)->dev(de639000)
Sep 23 14:46:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde7d5900, vcc=0xde741800)
Sep 23 14:46:33 pbx2 user.debug kernel: atm_skb(de7d5900)->vcc(de741800)->dev(de639000)
Sep 23 14:46:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:38 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:38 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80, vcc=0xde741800)
Sep 23 14:46:38 pbx2 user.debug kernel: atm_skb(de660a80)->vcc(de741800)->dev(de639000)
Sep 23 14:46:48 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:48 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8320, vcc=0xde741800)
Sep 23 14:46:48 pbx2 user.debug kernel: atm_skb(df2b8320)->vcc(de741800)->dev(de639000)
Sep 23 14:46:53 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80, vcc=0xde741800)
Sep 23 14:46:53 pbx2 user.debug kernel: atm_skb(de660a80)->vcc(de741800)->dev(de639000)
Sep 23 14:46:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:58 pbx2 user.debug kernel: pppoatm push
Sep 23 14:46:58 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8860, vcc=0xde741800)
Sep 23 14:46:58 pbx2 user.debug kernel: atm_skb(df2b8860)->vcc(de741800)->dev(de639000)
Sep 23 14:47:08 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:08 pbx2 user.debug kernel: pppoatm_send (skb=0xdf0ccee0, vcc=0xde741800)
Sep 23 14:47:08 pbx2 user.debug kernel: atm_skb(df0ccee0)->vcc(de741800)->dev(de639000)
Sep 23 14:47:13 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a980, vcc=0xde741800)
Sep 23 14:47:13 pbx2 user.debug kernel: atm_skb(de74a980)->vcc(de741800)->dev(de639000)
Sep 23 14:47:13 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:18 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:18 pbx2 user.debug kernel: pppoatm_send (skb=0xcb0e8b20, vcc=0xde741800)
Sep 23 14:47:18 pbx2 user.debug kernel: atm_skb(cb0e8b20)->vcc(de741800)->dev(de639000)
Sep 23 14:47:28 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:28 pbx2 user.debug kernel: pppoatm_send (skb=0xcb063540, vcc=0xde741800)
Sep 23 14:47:28 pbx2 user.debug kernel: atm_skb(cb063540)->vcc(de741800)->dev(de639000)
Sep 23 14:47:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde7d5600, vcc=0xde741800)
Sep 23 14:47:33 pbx2 user.debug kernel: atm_skb(de7d5600)->vcc(de741800)->dev(de639000)
Sep 23 14:47:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:38 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:38 pbx2 user.debug kernel: pppoatm_send (skb=0xcb058bc0, vcc=0xde741800)
Sep 23 14:47:38 pbx2 user.debug kernel: atm_skb(cb058bc0)->vcc(de741800)->dev(de639000)
Sep 23 14:47:48 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:48 pbx2 user.debug kernel: pppoatm_send (skb=0xde7d5540, vcc=0xde741800)
Sep 23 14:47:48 pbx2 user.debug kernel: atm_skb(de7d5540)->vcc(de741800)->dev(de639000)
Sep 23 14:47:53 pbx2 user.debug kernel: pppoatm_send (skb=0xde7037a0, vcc=0xde741800)
Sep 23 14:47:53 pbx2 user.debug kernel: atm_skb(de7037a0)->vcc(de741800)->dev(de639000)
Sep 23 14:47:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:54 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:54 pbx2 user.info kernel: AIF:UNPRIV TCP packet: IN=ppp0 OUT= MAC= SRC=222.178.228.162 DST=97.120.34.38 LEN=40 TOS=0x00 PREC=0x00 TTL=104 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Sep 23 14:47:58 pbx2 user.debug kernel: pppoatm push
Sep 23 14:47:58 pbx2 user.debug kernel: pppoatm_send (skb=0xde660480, vcc=0xde741800)
Sep 23 14:47:58 pbx2 user.debug kernel: atm_skb(de660480)->vcc(de741800)->dev(de639000)
Sep 23 14:48:08 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:08 pbx2 user.debug kernel: pppoatm_send (skb=0xde6d0740, vcc=0xde741800)
Sep 23 14:48:08 pbx2 user.debug kernel: atm_skb(de6d0740)->vcc(de741800)->dev(de639000)
Sep 23 14:48:13 pbx2 user.debug kernel: pppoatm_send (skb=0xcb058ec0, vcc=0xde741800)
Sep 23 14:48:13 pbx2 user.debug kernel: atm_skb(cb058ec0)->vcc(de741800)->dev(de639000)
Sep 23 14:48:13 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:18 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:18 pbx2 user.debug kernel: pppoatm_send (skb=0xcb058740, vcc=0xde741800)
Sep 23 14:48:18 pbx2 user.debug kernel: atm_skb(cb058740)->vcc(de741800)->dev(de639000)
Sep 23 14:48:28 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:28 pbx2 user.debug kernel: pppoatm_send (skb=0xde7d5540, vcc=0xde741800)
Sep 23 14:48:28 pbx2 user.debug kernel: atm_skb(de7d5540)->vcc(de741800)->dev(de639000)
Sep 23 14:48:33 pbx2 user.debug kernel: pppoatm_send (skb=0xcb10ab60, vcc=0xde741800)
Sep 23 14:48:33 pbx2 user.debug kernel: atm_skb(cb10ab60)->vcc(de741800)->dev(de639000)
Sep 23 14:48:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:38 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:38 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a380, vcc=0xde741800)
Sep 23 14:48:38 pbx2 user.debug kernel: atm_skb(de74a380)->vcc(de741800)->dev(de639000)
Sep 23 14:48:48 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:48 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8ce0, vcc=0xde741800)
Sep 23 14:48:48 pbx2 user.debug kernel: atm_skb(df2b8ce0)->vcc(de741800)->dev(de639000)
Sep 23 14:48:53 pbx2 user.debug kernel: pppoatm_send (skb=0xdf0cc3a0, vcc=0xde741800)
Sep 23 14:48:53 pbx2 user.debug kernel: atm_skb(df0cc3a0)->vcc(de741800)->dev(de639000)
Sep 23 14:48:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:58 pbx2 user.debug kernel: pppoatm push
Sep 23 14:48:58 pbx2 user.debug kernel: pppoatm_send (skb=0xdf0cc5e0, vcc=0xde741800)
Sep 23 14:48:58 pbx2 user.debug kernel: atm_skb(df0cc5e0)->vcc(de741800)->dev(de639000)
Sep 23 14:49:08 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:08 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8c20, vcc=0xde741800)
Sep 23 14:49:08 pbx2 user.debug kernel: atm_skb(df2b8c20)->vcc(de741800)->dev(de639000)
Sep 23 14:49:13 pbx2 user.debug kernel: pppoatm_send (skb=0xcb0636c0, vcc=0xde741800)
Sep 23 14:49:13 pbx2 user.debug kernel: atm_skb(cb0636c0)->vcc(de741800)->dev(de639000)
Sep 23 14:49:13 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:18 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:18 pbx2 user.debug kernel: pppoatm_send (skb=0xde6d0440, vcc=0xde741800)
Sep 23 14:49:18 pbx2 user.debug kernel: atm_skb(de6d0440)->vcc(de741800)->dev(de639000)
Sep 23 14:49:27 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:27 pbx2 user.info kernel: AIF:PRIV TCP packet: IN=ppp0 OUT= MAC= SRC=95.30.151.99 DST=97.120.34.38 LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=4558 DF PROTO=TCP SPT=2353 DPT=445 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 23 14:49:29 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:29 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8320, vcc=0xde741800)
Sep 23 14:49:29 pbx2 user.debug kernel: atm_skb(df2b8320)->vcc(de741800)->dev(de639000)
Sep 23 14:49:30 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:30 pbx2 user.info kernel: AIF:PRIV TCP packet: IN=ppp0 OUT= MAC= SRC=95.30.151.99 DST=97.120.34.38 LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=5041 DF PROTO=TCP SPT=2353 DPT=445 WINDOW=65535 RES=0x00 SYN URGP=0
Sep 23 14:49:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde7037a0, vcc=0xde741800)
Sep 23 14:49:33 pbx2 user.debug kernel: atm_skb(de7037a0)->vcc(de741800)->dev(de639000)
Sep 23 14:49:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:39 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:39 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8260, vcc=0xde741800)
Sep 23 14:49:39 pbx2 user.debug kernel: atm_skb(df2b8260)->vcc(de741800)->dev(de639000)
Sep 23 14:49:49 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:49 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a2c0, vcc=0xde741800)
Sep 23 14:49:49 pbx2 user.debug kernel: atm_skb(de74a2c0)->vcc(de741800)->dev(de639000)
Sep 23 14:49:53 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b89e0, vcc=0xde741800)
Sep 23 14:49:53 pbx2 user.debug kernel: atm_skb(df2b89e0)->vcc(de741800)->dev(de639000)
Sep 23 14:49:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:59 pbx2 user.debug kernel: pppoatm push
Sep 23 14:49:59 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8260, vcc=0xde741800)
Sep 23 14:49:59 pbx2 user.debug kernel: atm_skb(df2b8260)->vcc(de741800)->dev(de639000)
Sep 23 14:50:04 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:04 pbx2 user.info kernel: AIF:PRIV TCP packet: IN=ppp0 OUT= MAC= SRC=87.18.248.240 DST=97.120.34.38 LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=34274 DF PROTO=TCP SPT=2936 DPT=445 WINDOW=64800 RES=0x00 SYN URGP=0
Sep 23 14:50:07 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:07 pbx2 user.info kernel: AIF:PRIV TCP packet: IN=ppp0 OUT= MAC= SRC=87.18.248.240 DST=97.120.34.38 LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=34537 DF PROTO=TCP SPT=2936 DPT=445 WINDOW=64800 RES=0x00 SYN URGP=0
Sep 23 14:50:09 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:09 pbx2 user.debug kernel: pppoatm_send (skb=0xcb058680, vcc=0xde741800)
Sep 23 14:50:09 pbx2 user.debug kernel: atm_skb(cb058680)->vcc(de741800)->dev(de639000)
Sep 23 14:50:10 pbx2 daemon.info hostapd: ap0: STA f8:1e:df:dd:e0:5b WPA: group key handshake completed (RSN)
Sep 23 14:50:10 pbx2 daemon.info hostapd: ap0: STA f8:1e:df:1e:c2:23 WPA: group key handshake completed (RSN)
Sep 23 14:50:10 pbx2 daemon.info hostapd: ap0: STA f8:1e:df:dd:e0:5b WPA: received EAPOL-Key 2/2 Group with unexpected replay counter
Sep 23 14:50:10 pbx2 daemon.info hostapd: ap0: STA f8:1e:df:1e:c2:23 WPA: received EAPOL-Key 2/2 Group with unexpected replay counter
Sep 23 14:50:13 pbx2 user.debug kernel: pppoatm_send (skb=0xde7d5240, vcc=0xde741800)
Sep 23 14:50:13 pbx2 user.debug kernel: atm_skb(de7d5240)->vcc(de741800)->dev(de639000)
Sep 23 14:50:13 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:19 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:19 pbx2 user.debug kernel: pppoatm_send (skb=0xde6d0c80, vcc=0xde741800)
Sep 23 14:50:19 pbx2 user.debug kernel: atm_skb(de6d0c80)->vcc(de741800)->dev(de639000)
Sep 23 14:50:29 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:29 pbx2 user.debug kernel: pppoatm_send (skb=0xde6600c0, vcc=0xde741800)
Sep 23 14:50:29 pbx2 user.debug kernel: atm_skb(de6600c0)->vcc(de741800)->dev(de639000)
Sep 23 14:50:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a500, vcc=0xde741800)
Sep 23 14:50:33 pbx2 user.debug kernel: atm_skb(de74a500)->vcc(de741800)->dev(de639000)
Sep 23 14:50:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:39 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:39 pbx2 user.debug kernel: pppoatm_send (skb=0xde660600, vcc=0xde741800)
Sep 23 14:50:39 pbx2 user.debug kernel: atm_skb(de660600)->vcc(de741800)->dev(de639000)
Sep 23 14:50:49 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:49 pbx2 user.debug kernel: pppoatm_send (skb=0xde7d53c0, vcc=0xde741800)
Sep 23 14:50:49 pbx2 user.debug kernel: atm_skb(de7d53c0)->vcc(de741800)->dev(de639000)
Sep 23 14:50:53 pbx2 user.debug kernel: pppoatm_send (skb=0xdf0cc220, vcc=0xde741800)
Sep 23 14:50:53 pbx2 user.debug kernel: atm_skb(df0cc220)->vcc(de741800)->dev(de639000)
Sep 23 14:50:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:59 pbx2 user.debug kernel: pppoatm push
Sep 23 14:50:59 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a5c0, vcc=0xde741800)
Sep 23 14:50:59 pbx2 user.debug kernel: atm_skb(de74a5c0)->vcc(de741800)->dev(de639000)
Sep 23 14:51:09 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:09 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b89e0, vcc=0xde741800)
Sep 23 14:51:09 pbx2 user.debug kernel: atm_skb(df2b89e0)->vcc(de741800)->dev(de639000)
Sep 23 14:51:13 pbx2 user.debug kernel: pppoatm_send (skb=0xcb058680, vcc=0xde741800)
Sep 23 14:51:13 pbx2 user.debug kernel: atm_skb(cb058680)->vcc(de741800)->dev(de639000)
Sep 23 14:51:13 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:19 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:19 pbx2 user.debug kernel: pppoatm_send (skb=0xde7930a0, vcc=0xde741800)
Sep 23 14:51:19 pbx2 user.debug kernel: atm_skb(de7930a0)->vcc(de741800)->dev(de639000)
Sep 23 14:51:29 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:29 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b89e0, vcc=0xde741800)
Sep 23 14:51:29 pbx2 user.debug kernel: atm_skb(df2b89e0)->vcc(de741800)->dev(de639000)
Sep 23 14:51:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a380, vcc=0xde741800)
Sep 23 14:51:33 pbx2 user.debug kernel: atm_skb(de74a380)->vcc(de741800)->dev(de639000)
Sep 23 14:51:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:39 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:39 pbx2 user.debug kernel: pppoatm_send (skb=0xde6d0740, vcc=0xde741800)
Sep 23 14:51:39 pbx2 user.debug kernel: atm_skb(de6d0740)->vcc(de741800)->dev(de639000)
Sep 23 14:51:49 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:49 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80, vcc=0xde741800)
Sep 23 14:51:49 pbx2 user.debug kernel: atm_skb(de660a80)->vcc(de741800)->dev(de639000)
Sep 23 14:51:53 pbx2 user.debug kernel: pppoatm_send (skb=0xde660e40, vcc=0xde741800)
Sep 23 14:51:53 pbx2 user.debug kernel: atm_skb(de660e40)->vcc(de741800)->dev(de639000)
Sep 23 14:51:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:59 pbx2 user.debug kernel: pppoatm push
Sep 23 14:51:59 pbx2 user.debug kernel: pppoatm_send (skb=0xcb10ace0, vcc=0xde741800)
Sep 23 14:51:59 pbx2 user.debug kernel: atm_skb(cb10ace0)->vcc(de741800)->dev(de639000)
Sep 23 14:52:09 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:09 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a500, vcc=0xde741800)
Sep 23 14:52:09 pbx2 user.debug kernel: atm_skb(de74a500)->vcc(de741800)->dev(de639000)
Sep 23 14:52:13 pbx2 user.debug kernel: pppoatm_send (skb=0xcb10a4a0, vcc=0xde741800)
Sep 23 14:52:13 pbx2 user.debug kernel: atm_skb(cb10a4a0)->vcc(de741800)->dev(de639000)
Sep 23 14:52:13 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:19 pbx2 user.warn kernel: eth1: Transmit timeout, status c 2b 484 0
Sep 23 14:52:19 pbx2 user.warn kernel: ------------[ cut here ]------------
Sep 23 14:52:19 pbx2 user.warn kernel: WARNING: at kernel/softirq.c:136 local_bh_enable+0x2f/0x76()
Sep 23 14:52:19 pbx2 user.warn kernel: Modules linked in: binfmt_misc aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle iptable_filter xt_multiport xt_state xt_limit xt_conntrack
Sep 23 14:52:19 pbx2 user.warn kernel: Pid: 0, comm: swapper Tainted: P W 2.6.27.49-astlinux #1
Sep 23 14:52:19 pbx2 user.warn kernel: [<c01153de>] warn_on_slowpath+0x40/0x63
Sep 23 14:52:19 pbx2 user.warn kernel: [<c01be378>] cipher_crypt_unaligned+0x6f/0xa7
Sep 23 14:52:19 pbx2 user.warn kernel: [<c01065e8>] read_tsc+0x6/0x22
Sep 23 14:52:19 pbx2 user.warn kernel: [<c012899e>] getnstimeofday+0x4a/0xc7
Sep 23 14:52:19 pbx2 user.warn kernel: [<c01267c2>] ktime_get_ts+0x1d/0x3f
Sep 23 14:52:19 pbx2 user.warn kernel: [<c012604e>] hrtimer_forward+0xe2/0xfe
Sep 23 14:52:19 pbx2 user.warn kernel: [<c014d80e>] free_block+0xb3/0xef
Sep 23 14:52:19 pbx2 user.warn kernel: [<c02aa0e1>] __atomic_notifier_call_chain+0x19/0x36
Sep 23 14:52:19 pbx2 user.warn kernel: [<c011915d>] local_bh_enable+0x2f/0x76
Sep 23 14:52:19 pbx2 user.warn kernel: [<e01a8f8a>] destroy_conntrack+0xb8/0xd7 [nf_conntrack]
Sep 23 14:52:19 pbx2 user.warn kernel: [<c0266262>] nf_conntrack_destroy+0x1e/0x34
Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da41>] skb_release_all+0x80/0xbd
Sep 23 14:52:19 pbx2 user.warn kernel: [<c024da9c>] __kfree_skb+0x8/0x61
Sep 23 14:52:19 pbx2 user.warn kernel: [<e0017589>] cp_clean_rings+0xbb/0xf8 [8139cp]
Sep 23 14:52:19 pbx2 user.warn kernel: [<e0018b58>] cp_tx_timeout+0x6b/0xca [8139cp]
Sep 23 14:52:19 pbx2 user.warn kernel: [<c025df4b>] dev_watchdog+0x0/0x176
Sep 23 14:52:19 pbx2 user.warn kernel: [<c025e051>] dev_watchdog+0x106/0x176
Sep 23 14:52:19 pbx2 user.warn kernel: [<e0097f3c>] coretimer_func+0xb1/0x133 [dahdi]
Sep 23 14:52:19 pbx2 user.warn kernel: [<c011c052>] run_timer_softirq+0x116/0x17a
Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118cdc>] __do_softirq+0x35/0x75
Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118d3e>] do_softirq+0x22/0x26
Sep 23 14:52:19 pbx2 user.warn kernel: [<c0118f18>] irq_exit+0x25/0x30
Sep 23 14:52:19 pbx2 user.warn kernel: [<c010477c>] do_IRQ+0x4d/0x5d
Sep 23 14:52:19 pbx2 user.warn kernel: [<c010394b>] common_interrupt+0x23/0x28
Sep 23 14:52:19 pbx2 user.warn kernel: [<c0106f3d>] default_idle+0x25/0x38
Sep 23 14:52:19 pbx2 user.warn kernel: [<c010254b>] cpu_idle+0x37/0x5f
Sep 23 14:52:19 pbx2 user.warn kernel: =======================
Sep 23 14:52:19 pbx2 user.warn kernel: ---[ end trace 4f9198b05afcf39f ]---
Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:19 pbx2 user.debug kernel: pppoatm_send (skb=0xde660c00, vcc=0xde741800)
Sep 23 14:52:19 pbx2 user.debug kernel: atm_skb(de660c00)->vcc(de741800)->dev(de639000)
Sep 23 14:52:29 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:29 pbx2 user.debug kernel: pppoatm_send (skb=0xcb10ab60, vcc=0xde741800)
Sep 23 14:52:29 pbx2 user.debug kernel: atm_skb(cb10ab60)->vcc(de741800)->dev(de639000)
Sep 23 14:52:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde6f8cc0, vcc=0xde741800)
Sep 23 14:52:33 pbx2 user.debug kernel: atm_skb(de6f8cc0)->vcc(de741800)->dev(de639000)
Sep 23 14:52:33 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:39 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:39 pbx2 user.debug kernel: pppoatm_send (skb=0xcb063480, vcc=0xde741800)
Sep 23 14:52:39 pbx2 user.debug kernel: atm_skb(cb063480)->vcc(de741800)->dev(de639000)
Sep 23 14:52:49 pbx2 user.debug kernel: pppoatm push
Sep 23 14:52:49 pbx2 user.debug kernel: pppoatm_send (skb=0xcb058980, vcc=0xde741800)
Sep 23 14:52:49 pbx2 user.debug kernel: atm_skb(cb058980)->vcc(de741800)->dev(de639000)
Sep 23 14:52:53 pbx2 user.debug kernel: pppoatm_send (skb=0xde793a60, vcc=0xde741800)
Sep 23 14:52:53 pbx2 user.debug kernel: atm_skb(de793a60)->vcc(de741800)->dev(de639000)
Sep 23 14:52:53 pbx2 user.debug kernel: pppoatm push
Sep 23 14:53:13 pbx2 user.debug kernel: pppoatm_send (skb=0xdf2b8620, vcc=0xde741800)
Sep 23 14:53:13 pbx2 user.debug kernel: atm_skb(df2b8620)->vcc(de741800)->dev(de639000)
Sep 23 14:53:33 pbx2 user.debug kernel: pppoatm_send (skb=0xde793a60, vcc=0xde741800)
Sep 23 14:53:33 pbx2 user.debug kernel: atm_skb(de793a60)->vcc(de741800)->dev(de639000)
Sep 23 14:53:53 pbx2 user.debug kernel: pppoatm_send (skb=0xde7037a0, vcc=0xde741800)
Sep 23 14:53:53 pbx2 user.debug kernel: atm_skb(de7037a0)->vcc(de741800)->dev(de639000)
Sep 23 14:54:13 pbx2 daemon.info pppd[1606]: No response to 3 echo-requests
Sep 23 14:54:13 pbx2 daemon.notice pppd[1606]: Serial link appears to be disconnected.
Sep 23 14:54:13 pbx2 daemon.info pppd[1606]: Connect time 173.7 minutes.
Sep 23 14:54:13 pbx2 daemon.info pppd[1606]: Sent 0 bytes, received 7898 bytes.
Sep 23 14:54:13 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x3 "Peer not responding"]
Sep 23 14:54:13 pbx2 user.debug kernel: pppoatm_send (skb=0xde660a80, vcc=0xde741800)
Sep 23 14:54:13 pbx2 user.debug kernel: atm_skb(de660a80)->vcc(de741800)->dev(de639000)
Sep 23 14:54:16 pbx2 daemon.debug pppd[1606]: sent [LCP TermReq id=0x4 "Peer not responding"]
Sep 23 14:54:16 pbx2 user.debug kernel: pppoatm_send (skb=0xde74a980, vcc=0xde741800)
Sep 23 14:54:16 pbx2 user.debug kernel: atm_skb(de74a980)->vcc(de741800)->dev(de639000)
Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Connection terminated.
Sep 23 14:54:19 pbx2 daemon.notice pppd[1606]: Modem hangup
Sep 23 14:54:19 pbx2 user.debug kernel: pppoatm push
Sep 23 14:54:19 pbx2 user.debug kernel: removing ATMPPP VCC de7752a0
|
|
From: Karl H. <ka...@hi...> - 2010-09-23 19:18:51
|
On 09/23/10 21:00, Philip Prindeville wrote: > > Note that I'm building the solos driver from "openadsl" on sourceforge > (since I'm running 2.6.27.49), not whatever is currently in 2.6.33 or > 2.6.35 stable. > It wont' work with that version unless it's patched with the atm_dev_signal_change() call. It's only a 3 line change but needs to be the same as this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f Thanks. Karl |
|
From: Philip P. <phi...@re...> - 2010-09-23 19:02:04
|
On 9/23/10 10:47 AM, Karl Hiramoto wrote: > New patch attached that should fix the "scheduling while atomic". I also > added a bunch of debug printk's so we can hopefully figure out what is > happening. Send the dmesg output when un/plugging the cable. I > assume the solos-pci driver does this well and calls > atm_dev_signal_change(). > > -- > Karl > > Rebooting... Note that I'm building the solos driver from "openadsl" on sourceforge (since I'm running 2.6.27.49), not whatever is currently in 2.6.33 or 2.6.35 stable. |
|
From: Karl H. <ka...@hi...> - 2010-09-23 17:47:21
|
On 09/23/10 19:02, Philip Prindeville wrote: > What I'm seeing in user-space is: > >>>>> Link up > pbx2 ~ # ip link show ppp0 > 8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > >>>>> cable unplugged > pbx2 ~ # ip link show ppp0 > 8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > pbx2 ~ # ip link show ppp0 > 8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > pbx2 ~ # ip link show ppp0 > 8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > >>>>> cable plugged back in, carrier restored > pbx2 ~ # ip link show ppp0 > 22: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast state UNKNOWN qlen 3 > link/ppp > pbx2 ~ # > so LOWER_UP is not changing.... > What's the "8" vs. "22"? (And is 3 an appropriate queue length?) Those are the interface indexes. When you create a new interface you get a new index. One way to read this in userspace is to see "man if_nametoindex". qlen 3 is pretty small on a DSL line with a high upload speed.. I usually use between 10 and 100. It also depends a lot on your DSL hardware and how much internal buffering/queuing it has, and how much other load is on your system. On a xscale 266mhz router with DSL with 1mbit upload, i needed qlen closer to 100 to max out the line, when the machine was also saturated with IRQs comming from network interfaces, CompatFlash on PCI bus, and other hardware. New patch attached that should fix the "scheduling while atomic". I also added a bunch of debug printk's so we can hopefully figure out what is happening. Send the dmesg output when un/plugging the cable. I assume the solos-pci driver does this well and calls atm_dev_signal_change(). -- Karl |
|
From: Philip P. <phi...@re...> - 2010-09-23 17:04:35
|
On 9/22/10 8:21 AM, Karl Hiramoto wrote:
> On 09/22/10 16:21, chas williams - CONTRACTOR wrote:
>> On Tue, 21 Sep 2010 21:19:45 -0700
>> Philip Prindeville<phi...@re...> wrote:
>>
>>
>>> BUG: unable to handle kernel NULL pointer dereference at 00000090
>> like it said, null pointer dereference. i.e. (null)->something
>>
>>> IP: [<e0133050>] :ppp_generic:ppp_channel_carrier_on+0x16/0x31
>> very early in ppp_channel_carrier_on() which means it is likely
>> 'struct channel *pch = chan->ppp;' where chan is null for some reason.
>> there could be an ordering issue here. pvcc->chan might not be
>> assigned by the time the event is ready to fire. it is reasonable to
>> expect that the carrier status of the hardware device will change
>> before the vcc is even assigned to the ppp layer.
>>
>>
> Yeah, thats exactly what it is. The last version of the patch i sent
> checks "if (pch->ppp)"
>
> in pppoatm when ppp_register_channel() is called the PPP channel is not
> yet connected so pch->ppp is null.
What I'm seeing in user-space is:
>>>> Link up
pbx2 ~ # ip link show ppp0
8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
>>>> cable unplugged
pbx2 ~ # ip link show ppp0
8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
pbx2 ~ # ip link show ppp0
8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
pbx2 ~ # ip link show ppp0
8: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
>>>> cable plugged back in, carrier restored
pbx2 ~ # ip link show ppp0
22: ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
pbx2 ~ #
What's the "8" vs. "22"? (And is 3 an appropriate queue length?)
Also seeing from dmesg:
PPP generic driver version 2.4.2
NET: Registered protocol family 24
Device: 0 Vpi: 0 Vci: 32
ip_tables: (C) 2000-2006 Netfilter Core Team
nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
device ap0 entered promiscuous mode
br1: topology change detected, propagating
br1: port 3(ap0) entering forwarding state
BUG: scheduling while atomic: pppd/1606/0x00000002
Modules linked in: binfmt_misc aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle iptable_filter xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip_tables x_tables pppoatm pppox ppp_generic slhc bridge stp llc solos_pci atm dummy ath5k mac80211 ath cfg80211 rfkill_backport compat dahdi sha512_generic sha256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher 8139cp rtc lm90 hwmon i2c_core cs5535_gpio
Pid: 1606, comm: pppd Tainted: P 2.6.27.49-astlinux #1
[<c02a6fd4>] schedule+0x62/0x28b
[<c02a757b>] schedule_timeout+0x13/0x8f
[<c02a740d>] wait_for_common+0xb1/0x11a
[<c0112437>] default_wake_function+0x0/0x8
[<c012214e>] synchronize_rcu+0x2a/0x2f
[<c012216b>] wakeme_after_rcu+0x0/0x8
[<c0127431>] atomic_notifier_chain_unregister+0x33/0x38
[<e01170e3>] pppoatm_push+0x51/0x181 [pppoatm]
[<e0086b46>] vcc_release+0x55/0xdf [atm]
[<c0249043>] sock_release+0x11/0x68
[<c024949b>] sock_close+0x26/0x2a
[<c0150fa0>] __fput+0x88/0x13b
[<c014ed58>] filp_close+0x4d/0x53
[<c014fdbf>] sys_close+0x6d/0xb6
[<c01037e6>] syscall_call+0x7/0xb
=======================
Device: 0 Vpi: 0 Vci: 32
BUG: scheduling while atomic: pppd/1606/0x00000002
Modules linked in: binfmt_misc aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle iptable_filter xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip_tables x_tables pppoatm pppox ppp_generic slhc bridge stp llc solos_pci atm dummy ath5k mac80211 ath cfg80211 rfkill_backport compat dahdi sha512_generic sha256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher 8139cp rtc lm90 hwmon i2c_core cs5535_gpio
Pid: 1606, comm: pppd Tainted: P 2.6.27.49-astlinux #1
[<c02a6fd4>] schedule+0x62/0x28b
[<c02a757b>] schedule_timeout+0x13/0x8f
[<c02a740d>] wait_for_common+0xb1/0x11a
[<c0112437>] default_wake_function+0x0/0x8
[<c012214e>] synchronize_rcu+0x2a/0x2f
[<c012216b>] wakeme_after_rcu+0x0/0x8
[<c0127431>] atomic_notifier_chain_unregister+0x33/0x38
[<e01170e3>] pppoatm_push+0x51/0x181 [pppoatm]
[<e0086b46>] vcc_release+0x55/0xdf [atm]
[<c0249043>] sock_release+0x11/0x68
[<c024949b>] sock_close+0x26/0x2a
[<c0150fa0>] __fput+0x88/0x13b
[<c014ed58>] filp_close+0x4d/0x53
[<c014fdbf>] sys_close+0x6d/0xb6
[<c01037e6>] syscall_call+0x7/0xb
=======================
Device: 0 Vpi: 0 Vci: 32
BUG: scheduling while atomic: pppd/1606/0x00000002
Modules linked in: binfmt_misc aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle iptable_filter xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip_tables x_tables pppoatm pppox ppp_generic slhc bridge stp llc solos_pci atm dummy ath5k mac80211 ath cfg80211 rfkill_backport compat dahdi sha512_generic sha256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher 8139cp rtc lm90 hwmon i2c_core cs5535_gpio
Pid: 1606, comm: pppd Tainted: P 2.6.27.49-astlinux #1
[<c02a6fd4>] schedule+0x62/0x28b
[<c02a757b>] schedule_timeout+0x13/0x8f
[<c02a740d>] wait_for_common+0xb1/0x11a
[<c0112437>] default_wake_function+0x0/0x8
[<c012214e>] synchronize_rcu+0x2a/0x2f
[<c012216b>] wakeme_after_rcu+0x0/0x8
[<c0127431>] atomic_notifier_chain_unregister+0x33/0x38
[<e01170e3>] pppoatm_push+0x51/0x181 [pppoatm]
[<e0086b46>] vcc_release+0x55/0xdf [atm]
[<c0249043>] sock_release+0x11/0x68
[<c024949b>] sock_close+0x26/0x2a
[<c0150fa0>] __fput+0x88/0x13b
[<c014ed58>] filp_close+0x4d/0x53
[<c014fdbf>] sys_close+0x6d/0xb6
[<c01037e6>] syscall_call+0x7/0xb
=======================
Device: 0 Vpi: 0 Vci: 32
BUG: scheduling while atomic: pppd/1606/0x00000002
Modules linked in: binfmt_misc aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle iptable_filter xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip_tables x_tables pppoatm pppox ppp_generic slhc bridge stp llc solos_pci atm dummy ath5k mac80211 ath cfg80211 rfkill_backport compat dahdi sha512_generic sha256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher 8139cp rtc lm90 hwmon i2c_core cs5535_gpio
Pid: 1606, comm: pppd Tainted: P 2.6.27.49-astlinux #1
[<c02a6fd4>] schedule+0x62/0x28b
[<c02a757b>] schedule_timeout+0x13/0x8f
[<c02a740d>] wait_for_common+0xb1/0x11a
[<c0112437>] default_wake_function+0x0/0x8
[<c012214e>] synchronize_rcu+0x2a/0x2f
[<c012216b>] wakeme_after_rcu+0x0/0x8
[<c0127431>] atomic_notifier_chain_unregister+0x33/0x38
[<e01170e3>] pppoatm_push+0x51/0x181 [pppoatm]
[<e0086b46>] vcc_release+0x55/0xdf [atm]
[<c0249043>] sock_release+0x11/0x68
[<c024949b>] sock_close+0x26/0x2a
[<c0150fa0>] __fput+0x88/0x13b
[<c014ed58>] filp_close+0x4d/0x53
[<c014fdbf>] sys_close+0x6d/0xb6
[<c01037e6>] syscall_call+0x7/0xb
=======================
Device: 0 Vpi: 0 Vci: 32
BUG: scheduling while atomic: pppd/1606/0x00000002
Modules linked in: binfmt_misc aes_i586 aes_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_nat_ftp nf_nat nf_conntrack_ipv4 xt_TCPMSS ipt_LOG ipt_REJECT iptable_mangle iptable_filter xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip_tables x_tables pppoatm pppox ppp_generic slhc bridge stp llc solos_pci atm dummy ath5k mac80211 ath cfg80211 rfkill_backport compat dahdi sha512_generic sha256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher 8139cp rtc lm90 hwmon i2c_core cs5535_gpio
Pid: 1606, comm: pppd Tainted: P 2.6.27.49-astlinux #1
[<c02a6fd4>] schedule+0x62/0x28b
[<c02a757b>] schedule_timeout+0x13/0x8f
[<c02a740d>] wait_for_common+0xb1/0x11a
[<c0112437>] default_wake_function+0x0/0x8
[<c012214e>] synchronize_rcu+0x2a/0x2f
[<c012216b>] wakeme_after_rcu+0x0/0x8
[<c0127431>] atomic_notifier_chain_unregister+0x33/0x38
[<e01170e3>] pppoatm_push+0x51/0x181 [pppoatm]
[<e0086b46>] vcc_release+0x55/0xdf [atm]
[<c0249043>] sock_release+0x11/0x68
[<c024949b>] sock_close+0x26/0x2a
[<c0150fa0>] __fput+0x88/0x13b
[<c014ed58>] filp_close+0x4d/0x53
[<c014fdbf>] sys_close+0x6d/0xb6
[<c01037e6>] syscall_call+0x7/0xb
=======================
Device: 0 Vpi: 0 Vci: 32
|
|
From: chas w. - C. <ch...@cm...> - 2010-09-22 16:43:44
|
On Wed, 22 Sep 2010 18:25:11 +0200 Karl Hiramoto <ka...@hi...> wrote: > On 09/22/10 18:04, Philip Prindeville wrote: > > > Ok, that didn't crash. > > > > Now how is the state exposed into user-space? > > > > > > > > If you do "ip link" does it show LOWER_UP? Then if you loose carrier > does LOWER_UP disappear? > > If not, put some printk's in locations like ppp_channel_carrier_on() > ppp_channel_carrier_off() pppoatm_dev_event() to see what's happening. since the events might preceed the create of the netdev interaface, it is probably a good idea to update the netdev carrier's status when the netdev is finally registered. |
|
From: Philip P. <phi...@re...> - 2010-09-22 16:36:15
|
On 9/22/10 9:25 AM, Karl Hiramoto wrote: > On 09/22/10 18:04, Philip Prindeville wrote: > >> Ok, that didn't crash. >> >> Now how is the state exposed into user-space? >> >> >> > If you do "ip link" does it show LOWER_UP? Then if you loose carrier > does LOWER_UP disappear? > > If not, put some printk's in locations like ppp_channel_carrier_on() > ppp_channel_carrier_off() pppoatm_dev_event() to see what's happening. Actually, that was happening before... because I think ppp_generic marks the interface as up when negotiation completes, and down when it fails or when LCP echo times out. No, that's not right. I just grepped IFF_UP in drivers/net/ppp*.c and didn't get a hit (for setting it). I'll dig a bit more for where this is happening. |
|
From: Karl H. <ka...@hi...> - 2010-09-22 16:25:08
|
On 09/22/10 18:04, Philip Prindeville wrote: > Ok, that didn't crash. > > Now how is the state exposed into user-space? > > > If you do "ip link" does it show LOWER_UP? Then if you loose carrier does LOWER_UP disappear? If not, put some printk's in locations like ppp_channel_carrier_on() ppp_channel_carrier_off() pppoatm_dev_event() to see what's happening. |
|
From: Philip P. <phi...@re...> - 2010-09-22 16:06:18
|
On 9/22/10 8:21 AM, Karl Hiramoto wrote: > On 09/22/10 16:21, chas williams - CONTRACTOR wrote: >> On Tue, 21 Sep 2010 21:19:45 -0700 >> Philip Prindeville<phi...@re...> wrote: >> >> >>> BUG: unable to handle kernel NULL pointer dereference at 00000090 >> like it said, null pointer dereference. i.e. (null)->something >> >>> IP: [<e0133050>] :ppp_generic:ppp_channel_carrier_on+0x16/0x31 >> very early in ppp_channel_carrier_on() which means it is likely >> 'struct channel *pch = chan->ppp;' where chan is null for some reason. >> there could be an ordering issue here. pvcc->chan might not be >> assigned by the time the event is ready to fire. it is reasonable to >> expect that the carrier status of the hardware device will change >> before the vcc is even assigned to the ppp layer. >> >> > Yeah, thats exactly what it is. The last version of the patch i sent > checks "if (pch->ppp)" > > in pppoatm when ppp_register_channel() is called the PPP channel is not > yet connected so pch->ppp is null. Ok, that didn't crash. Now how is the state exposed into user-space? |
|
From: Karl H. <ka...@hi...> - 2010-09-22 15:21:14
|
On 09/22/10 16:21, chas williams - CONTRACTOR wrote: > On Tue, 21 Sep 2010 21:19:45 -0700 > Philip Prindeville <phi...@re...> wrote: > > >> BUG: unable to handle kernel NULL pointer dereference at 00000090 > > like it said, null pointer dereference. i.e. (null)->something > >> IP: [<e0133050>] :ppp_generic:ppp_channel_carrier_on+0x16/0x31 > > very early in ppp_channel_carrier_on() which means it is likely > 'struct channel *pch = chan->ppp;' where chan is null for some reason. > there could be an ordering issue here. pvcc->chan might not be > assigned by the time the event is ready to fire. it is reasonable to > expect that the carrier status of the hardware device will change > before the vcc is even assigned to the ppp layer. > > Yeah, thats exactly what it is. The last version of the patch i sent checks "if (pch->ppp)" in pppoatm when ppp_register_channel() is called the PPP channel is not yet connected so pch->ppp is null. |
34 messages has been excluded from this view by a project administrator.
