Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs
On 8/5/06, Joao Barros <[EMAIL PROTECTED]> wrote: On 8/4/06, Gleb Smirnoff <[EMAIL PROTECTED]> wrote: > On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote: > J> On 8/4/06, Gleb Smirnoff <[EMAIL PROTECTED]> wrote: > J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: > J> >J> Being this a cryptic message to say the least and to probably save > J> >J> someone some time when presented with this message I attach a patch > J> >J> that adds the header "pppoe:" in every printf that didn't have it, > J> >J> making it consistent with the rest of the file. > J> > > J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes > J> >all printf(9) to log(9). The latter is better since it spams console > J> >less, if event occurs many times per second. Also I've made the messages > J> >more clear - prepended node ID where possible, function name when it > J> >starts with ng_pppoe, or just "ng_pppoe". > J> > > J> >Can you please try out this patch and tell whether you like it. If you > J> >do I will commit it soon. > J> > J> Hi, > J> > J> I've looked at the patch and it looks ok. > J> It serves the purpose: make the messages more clear with the added > J> bonus of more info. > J> Thanks for taking the time to look into this :-) > > Since I don't use ng_pppoe now much, I'd appreciate if you > do at brief test of this patch, before I commit it. > I patched and recompiled the kernel. After booting I notice that no messages from ppp are logged by syslog (messages|ppp.log) If I restart ppp the messages are all logged. I can't say if this was happening because after setting ppp up I didn't reboot the machine. I didn't browse the startup scripts but maybe syslog is not started before pppoe. Now it will take more than 17 hours for the session limit to be exceeded and only then I can say how your patch worked out. I'll make an update then. Ok, here's the new output just before the connection was dropped (earlier than usual): Aug 5 07:28:50 ultra5 kernel: ng_pppoe[5]: session in wrong state Aug 5 07:28:50 ultra5 last message repeated 3 times Looks fine to me :-) -- Joao Barros ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pthreads memoty leak?
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
#include
#include
#include
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define size 1
int ret, i;
for (i = 0; i < size; i++) {
pthread_t t_id;
pthread_attr_t pthread_attr;
pthread_attr_init (&pthread_attr);
pthread_attr_setdetachstate (&pthread_attr,
PTHREAD_CREATE_DETACHED);
ret = pthread_create (&t_id, &pthread_attr, mythread, NULL);
pthread_attr_destroy (&pthread_attr);
if (ret)
printf ("pthread_create() returned error value %d\n", ret);
}
}
int main()
{
int i;
for (i = 0; i < 1000; i++) {
if (i % 1000 == 0)
printf ("main() iteration: %d\n", i);
threaded();
}
printf ("FINISHED.\n");
sleep (3600);
return 0;
}
==
--
Igor A. Valcov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: miibus + USB = problem ?
On Friday 04 August 2006 02:09, Pyun YongHyeon wrote: > On Thu, Aug 03, 2006 at 02:44:46PM +0200, Hans Petter Selasky wrote: > > On Thursday 03 August 2006 04:25, Pyun YongHyeon wrote: > > > On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote: > > I can't sure why you need to invoke kthread_exit(9) in aue_miibus_xxx. > If you want to kill the kernel thread in aue_miibus_xxx you can simply > send a termination message to kernel thread. Your kernel thread can > decide when it should terminate if it recevied a termination message. > Invoking mii_mediachg/mii_tick will end up with calling miibus_xxx to > to read/write PHY registers from MII layer. So I think you still need > to handle PHY read/write operations in aue_miibus_xxx. If the PHY > operation was failed due to removal of hardware it could simply return > fake value and send a message to terminate the kernel thread. Yes, I was thinking about the same. I changed the behaviour to return zero if the thread is gone, and delays are just short-circuited. That way the code will return to the main thread in a short time, hopefully, where I do a kthread_exit(0). --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC 919 compliance (broadcasts to 255.255.255.255)
On Saturday 05 August 2006 07:18, you wrote: > On Fri, 4 Aug 2006, Benjamin Lutz wrote: > > Hello, > > > > I've noticed that FreeBSD does not by default comply to RFC 919, Chapter > > 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle > > IP packets with a destination address of 255.255.255.255 properly. > > > > 255.255.255.255 is a "limited broadcast address" (the term is not > > mentioned in the RFC, but seems to be in use everywhere else). An IP > > packet send to that address should be broadcast to the whole IP subnet of > > the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does > > not work, as is evident by this tcpdump output: > > > > 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 > > (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id > > 33319, seq 0, length 64 > > > > The destination MAC address is that of my gateway, but it should be > > ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip > > proto 1" and "ping 255.255.255.255". > > > > I found a discussion from 2003 about this, but it seems to have trailed > > off without coming to a conclusion: > > http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html > > > > I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The > > intention seems to be to enable packets to 255.255.255.255. However a > > test with a small program showed that this option seems to have no > > effect, outgoing packets still carried the gateway's MAC address as > > destination. > > > > Btw, Linux and NetBSD both handle packets to 255.255.255.255 as > > broadcasts. > > > > Now, is this behaviour intentional? Is there a way to turn on RFC 919 > > compliance? If not, would someone be willing to add this to the kernel? > > Should I submit a PR? > > Does this feature really necessary? For waht purpose? I discovered it when playing with Wake-on-LAN packets. It is possible to send those with the real subnet's broadcast address, but then you first have to figure that one out. If you have a network device that doesn't have an IP configured yet, it would not know the subnet broadcast address. > I believe this feature is more harmful than useful. Please elaborate. Remember that routers do not pass on packets to 255.255.255.255. The TTL is effectively 1. Cheers Benjamin pgpa6Ook32YFw.pgp Description: PGP signature
jkh weird problem (reading pci device memory)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to port a linux driver to freebsd (hsdpa/umts nozomi card),
and i'm experiencing some really weird problem... probably due to my limited
kernel knowledge/experience.
Here it is the attach routine, which tries to read a portion of the device
memory into
a specially formatted struct. Then the first filed in the struct is compared to
a predefined value (a signature)
to make sure that the read was successfull. The problem is that right now this
only works if i do the printfs marked
with XXX. When i comment them the read returns something that looks to me like
random garbage...
probably i'm doing something very stupid, or missing something essential...
any insight is greatly appreciated.
Again, here is the original linux driver for reference :
http://www.pharscape.org/3G/nozomi_2.1_060703.tar.gz
P.S.: This is on 7.0-CURRENT
Thanks in advance!
Regards,
Niki Denev
[ code ]
int
nozomi_attach(device_t dev)
{
struct nozomi_softc *sc;
int i;
u_int8_t r;
sc = device_get_softc(dev);
sc->noz_dev = dev;
sc->bar.id = PCIR_BAR(0);
sc->bar.res = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->bar.id, 0,
~0, 1, RF_ACTIVE);
sc->bar.tag = rman_get_bustag(sc->bar.res);
sc->bar.hdl = rman_get_bushandle(sc->bar.res);
sc->base_addr = rman_get_start(sc->bar.res);
sc->virt_addr = rman_get_virtual(sc->bar.res);
/* set card type to F32_8 on no match */
sc->card_type = rman_get_size(sc->bar.res) == 2048 ? F32_2 : F32_8;
device_printf(sc->noz_dev, "card has %uKB memory\n", sc->card_type);
/* XXX if i don't print these the reading of the bus memory will be
incorrect */
printf("phys address 0x%08lx\n", sc->base_addr);
printf("virt address 0x%p\n", sc->virt_addr);
printf("cfg address 0x%p\n", &sc->cfg_table);
for(i=0; i < sizeof(config_table_t); i++) {
r = bus_space_read_1(sc->bar.tag, sc->bar.hdl, i);
*((u_int8_t *)&sc->cfg_table + i) = r;
}
if(sc->cfg_table.signature != CONFIG_MAGIC) {
printf("ConfigTable Bad! 0x%08X != 0x%08X\n",
sc->cfg_table.signature, CONFIG_MAGIC);
return(ENXIO);
}
[ code continues ... ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE1KXcHNAJ/fLbfrkRAhEZAKCvz1+ZBDH+mSMBLtoreAGDlzSL4wCgsZcL
yxziRoie0cqIFYCzdI4gAkk=
=6D/Y
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pthreads memoty leak?
Hi
The startup of this program causes memory leak, doesn't it? What's the
reason?
Tested on FreeBSD-6.1 and 5.4 with the same effect.
On Linux work fine.
#include
#include
#include
void* mythread(void* arg)
{
return NULL;
}
void threaded()
{
#define size 1
int ret, i;
for (i = 0; i < size; i++) {
pthread_t t_id;
pthread_attr_t pthread_attr;
pthread_attr_init (&pthread_attr);
pthread_attr_setdetachstate (&pthread_attr,
PTHREAD_CREATE_DETACHED);
ret = pthread_create (&t_id, &pthread_attr, mythread, NULL);
pthread_attr_destroy (&pthread_attr);
if (ret)
printf ("pthread_create() returned error value %d\n", ret);
}
}
int main()
{
int i;
for (i = 0; i < 1000; i++) {
if (i % 1000 == 0)
printf ("main() iteration: %d\n", i);
threaded();
}
printf ("FINISHED.\n");
sleep (3600);
return 0;
}
==
--
Igor A. Valcov
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
syslog bug ? (was Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs)
On Sat, Aug 05, 2006 at 12:42:12AM +0100, Joao Barros wrote: ... > I patched and recompiled the kernel. > After booting I notice that no messages from ppp are logged by syslog > (messages|ppp.log) What is your OS version ? i hit a similar problem some time ago, and it seems that the syslog client code remembers any error on the socket (e.g. ICMP host/port unreachable messages) and does not retry afterwards (or for some time, or there is some bug in handling the error condition). I am a bit fuzzy on the details because this was some 3 years ago on a 4.x client. Your problem is likely because ppp starts before the syslog daemon, the initial message fails and then you get nothing anymore. the vsyslog code in 6.x (libc/gen/syslog.c) is slightly different from the one in 4.11. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: syslog bug ? (was Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs)
On 8/5/06, Luigi Rizzo <[EMAIL PROTECTED]> wrote: On Sat, Aug 05, 2006 at 12:42:12AM +0100, Joao Barros wrote: ... > I patched and recompiled the kernel. > After booting I notice that no messages from ppp are logged by syslog > (messages|ppp.log) What is your OS version ? FreeBSD ultra5.bsdtech.org 6.1-RELEASE-p1 FreeBSD 6.1-RELEASE-p1 #1: Fri Aug 4 23:18:19 WEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ultra5 sparc64 Your problem is likely because ppp starts before the syslog daemon, the initial message fails and then you get nothing anymore. I guessed that much but I still haven't verified the init scripts. -- Joao Barros ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
