Re: Broken-by-design USB device?
The panic is definitely bad. It happens straight after failing the attach? If you could recompile the kernel with options DDB makeoptions DEBUG=-g plug the device in again, and after it has panicked (it will drop into the debugger), type trace. That would give me a hint at where it crashes. The controller probably requires some work because a fake report descriptor is needed to make it possible for the uhid driver to talk to it. It does not provide any information on where the information for the buttons and axes is stored in the descriptor returned on the interrupt pipe. Nick I've got a little USB device that allows Playstation controllers to be used on a PC. If it's plugged in while booting FreeBSD 4.2-RELEASE (the shipped GENERIC kernel), I get: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 3 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhid0: vendor 0x product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 uhid0: no report descriptor device_probe_and_attach: uhid0 attach returned 6 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc012663a stack pointer = 0x10:0xc044a938 frame pointer = 0x10:0xc044a938 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort After poking around in the uhid and usb code, I'm beginning to think that this adapter is just broken by design. Can someone a bit more familiar with the USB stuff comment on that? Thanks. For identifying what this is, there's not a lot of info available. It shows up in Windows as a "Monster Gamepad" with 4 analog axis and 16 buttons, and just has a single 20 pin DIPP chip inside with these markings (looks like a PLA to me): CY7C63000A-PC 9946 G 02 518003 --- Jon Simola [EMAIL PROTECTED] | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
To solve this problem, I invested in one large, fast, fileserver and then ran the noise-critical machines diskless, with PXE boot. To deal with the noise of the fileserver, I bought an enclosed rack. My previous solutions which did an admirable job, were to: a) purchase the overly expensive, quiet power supplies (you can find them easily by going to google and searching for 'quiet power supply' or some such similar thing) b) run fans under standard voltage, with an underclocked CPU c) use a small flash IDE device for boot d) use an old laptop Good luck! -- kevin way [EMAIL PROTECTED] worldgate communications software engineer +1 215 354 5287 PGP signature
Re: Broken-by-design USB device?
On 30-Dec-00 Nick Hibma wrote: For identifying what this is, there's not a lot of info available. It shows up in Windows as a "Monster Gamepad" with 4 analog axis and 16 buttons, and just has a single 20 pin DIPP chip inside with these markings (looks like a PLA to me): CY7C63000A-PC 9946 G 02 518003 FYI that part is made by Cypress... Basically it is an 8051 core with a low speed USB engine attached. The data sheet is at http://www.cypress.com/usb/lowspeed/cy7c63xxxa.html but it's not going to be much help without knowing how the firmware is coded. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OT: silence as an answer? (was: how to test out cron.c changes?)
[ this message is no personal affront against you, Doug, but an expression of what feeling this kind of behaviour causes for those who want to share and find themselves ignored ] On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: Gerhard Sittig wrote: [ ... reminder after two weeks of silence ... ] Two weeks of silence is generally enough to let you know that no one is interested in this modification. If someone was, they'd generally have said something by now. Well, I don't come to the same conclusion here as you do and I'm not so sure about it as you are. :) Silence as I see it is just a sign for "nobody answered", without a reason to see why. It could be work load or being offline or getting side tracked or whatever as well as being not interested or disagreeing. And finally I want to take the lack of disagreement (or the absence of its statement) as a sign for "it's not completely wrong what I want to do here". It could even be that the method of searching for contact or the way the proposal was presented has been wrong (in the past I had to learn that Jordan is more of a programmer and obviously is better at reading source than prose, so citing few lines of code had been more clear than one sentence "'cvs diff ... ' moved the test upwards and solved the panic":). At the moment I would like to believe that I just made a mistake in my proposal and that there is some kind of interest or serious rejection. BTW is rejection much more the kind of reaction I had expected in the case you describe (nobody wants it). This would have been at least *some* reaction. Getting ignored is definitely a fine way of discouraging future contributions. Some "we don't like the approach, since ..." or a simple "Nope" or even a serious "PLONK!" would have been great and as much appreciated as an "yes, we like it"! It had saved time and work for _everyone_ involved (me as being the originator as well as those I had to annoy repeatedly when they could have stopped me right in the beginning). The experience will make me think twice next time if I'm in the mood of spending my resources in the will to help and contribute just to find myself sitting there ignored. Would I really feel like having this kind of conversation, I could as well open my fridge and talk to it ... :-| Speaking only for myself, I don't think your proposed changes are a good idea, which is why I refrained from offering any suggestions on how you can test them. Well, this has been the very first and most important the only response. After I offered help in public to solve an "eternal problem" and spent some effort on it ... I'll start one more try (the last on this proposal) in a separate message in the hope that this OT message won't start a new thread or in case it should the thread would die really soon. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: Speaking only for myself, I don't think your proposed changes are a good idea, which is why I refrained from offering any suggestions on how you can test them. Your refusal(id?) has been the only response so far and it didn't sound very clear / determined / explained (sorry, I lack better words) to me. :) So I guess the wording I used "DST handling in cron" was not done luckily. Let me cite from the doc diff: - --- /usr/src/usr.sbin/cron/cron/cron.8 1999/08/28 01:15:49 1.7 +++ /usr/src/usr.sbin/cron/cron/cron.8 2000/12/03 12:44:53 @@ -68,6 +68,25 @@ .Xr crontab 1 command updates the modtime of the spool directory whenever it changes a crontab. +.Pp +Special considerations exist when the clock is changed by less than 3 +hours; for example, at the beginning and end of Daylight Saving +Time. +If the time has moved forward, those jobs which would have +run in the time that was skipped will be run soon after the change. +Conversely, if the time has moved backward by less than 3 hours, +those jobs that fall into the repeated time will not be run. +.Pp +Only jobs that run at a particular time (not specified as @hourly, nor with +.Ql * +in the hour or minute specifier) +are +affected. +Jobs which are specified with wildcards are run based on the +new time immediately. +.Pp +Clock changes of more than 3 hours are considered to be corrections to +the clock, and the new time is used immediately. .Sh SEE ALSO .Xr crontab 1 , .Xr crontab 5 - This modification (obtained from OpenBSD) handles any situation where system time will jump just a little (assuming you're willing to refer to three hours as "just a little" while talking about computers:). Think of administrators' intervention by means of date(8) or netdate(1) for manual correction. Or maybe DST changes, which are just a special case thereof. And yes, it sounds a little like the anacron method of keeping up with scheduled jobs while the machine hasn't been available continuously. But admittedly DST changes are the cause of permanently upcoming discussions twice a year that cron(8) is broken or crontab(5) needs correction -- with (always the same) result that touching the crontab database cannot solve the problem. And the latest commits to crontab that still didn't satisfy every region FreeBSD users live in were what triggered my wish to stuff the "intelligence" into cron(8) and live in peace for good (at least in this respect). Of course we could wait another few months to have the discussion come up once more (and to know for sure it will again and again). But I'd rather have some feedback whether the problem could be solved before the effect strikes again and whether it's worth to spend any more time on providing fixes people actually don't want to get in the end. Is there anyone out there who feels like rejecting the proposal for a *reason*? Or to accept the idea, but to redirect the effort to a "real solution"? I somehow doubt you'd rather explain again and again that cron(8) isn't broken but that users should shuffle around the daily job's execution time ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OT: silence as an answer? (was: how to test out cron.c changes?)
On Tue 2001-01-02 (12:52), Gerhard Sittig wrote: On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: Gerhard Sittig wrote: [ ... reminder after two weeks of silence ... ] Two weeks of silence is generally enough to let you know that no one is interested in this modification. If someone was, they'd generally have said something by now. Well, I don't come to the same conclusion here as you do and I'm not so sure about it as you are. :) Silence as I see it is just a sign for "nobody answered", without a reason to see why. It could be work load or being offline or getting side tracked or whatever as well as being not interested or disagreeing. And finally I want to take the lack of disagreement (or the absence of its statement) as a sign for "it's not completely wrong what I want to do here". I tend to agree here - silence could mean many things. In this case, I can't see why people wouldn't want this - it's something that gets brought up time and again. The experience will make me think twice next time if I'm in the mood of spending my resources in the will to help and contribute just to find myself sitting there ignored. Would I really feel like having this kind of conversation, I could as well open my fridge and talk to it ... :-| I think we can put this current silence down to holidays and getting sidetracked while trying to think of a reply - the question isn't particularly easy to answer, and people don't generally answer "I don't know". (: I remember reading this, and thinking "gee, what _is_ a good way to test DST changes?", and then promptly forgetting about it, because I never really deal with DST changes. I think the only way is the hard way - changing the date in increments and testing whether extra or no jobs are run. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Reprobing the ATAPI bus.
Does anyone know how to reprobe the ATAPI bus, e.g. for a cd rom drive in a laptop that wasn't present during boot? Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
It seems Josef Karthauser wrote: Does anyone know how to reprobe the ATAPI bus, e.g. for a cd rom drive in a laptop that wasn't present during boot? Yes :) Most of the code is already in the ATA driver, but the ioctl's and the atacontrol program is still only here in my lab due to lack of time... I hope to be able to devote enough time to this soon, I'm currently looking into having some of my time for this being sponsored... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP question.
Alfred Perlstein wrote: * Félix-Antoine Paradis [EMAIL PROTECTED] [010101 23:28] wrote: Hi, When we do a "dmesg" on a 4.2-STABLE box, we get: arp: 200.42.126.18 moved from 00:e0:7d:7b:53:f0 to 00:c0:df:f4:ac:05 on ed0 and, in ifconfig, it says: ed0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 200.42.126.20 netmask 0xff00 broadcast 200.42.126.255 inet6 fe80::2e0:7dff:fe7b:548a%ed0 prefixlen 64 scopeid 0x1 ether 00:e0:7d:7b:54:8a ed0 is connected to a switch. we want to know what the "arp: " message means. on the linux box, we have: eth0 Link encap:Ethernet HWaddr 00:C0:DF:F4:AC:05 inet addr:200.42.126.18 Bcast:200.42.126.23 Mask:255.255.255.248 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:12738748 errors:0 dropped:0 overruns:0 frame:556 TX packets:4014499 errors:0 dropped:0 overruns:0 carrier:0 collisions:172394 txqueuelen:100 Interrupt:10 Base address:0xe800 eth1 Link encap:Ethernet HWaddr 00:E0:7D:7B:53:F0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3634104 errors:0 dropped:0 overruns:0 frame:4 TX packets:3842298 errors:0 dropped:0 overruns:0 carrier:0 collisions:197818 txqueuelen:100 Interrupt:12 Base address:0xec00 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 Both eth0 and eth1 are connected to that same switch. If they are receiving each other's broadcasts then arp will get upset. (As you noticed) You should check /var/log/messages for the datestamp. Basically it means someone took someone's arp address either by 1) taking the IP from a different machine. 2) telling a machine to change its hardware address. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SecureBSD
On Fri, 29 Dec 2000, Wes Peters wrote: You may want to look at http://www.trustedbsd.org/ as well. It is provided under the Berkeley license, and much of what is developed there will be folded into FreeBSD as time permits. The primary author of TrustedBSD is Robert Watson, who is now a FreeBSD Core Team member as well. Actually, TrustedBSD seems to be in very early stages of development. For now, I've decided that the best solution for me would be `spy' KLD (www.freebsd.org - projects - SPY). //danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
On Tue, Jan 02, 2001 at 03:50:34PM +0100, Soren Schmidt wrote: It seems Josef Karthauser wrote: Does anyone know how to reprobe the ATAPI bus, e.g. for a cd rom drive in a laptop that wasn't present during boot? Yes :) Most of the code is already in the ATA driver, but the ioctl's and the atacontrol program is still only here in my lab due to lack of time... I hope to be able to devote enough time to this soon, I'm currently looking into having some of my time for this being sponsored... I'll sponser you. How about a penny per line of code :). I'll just reboot then whilst I wait ;p Thanks, Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
That could look/get ugly.
if
(
retval
==
-1
)
{
// blah
}
hehe ;P
-
Daryl Chance | And which parallel universe did
ValueData, LLC | YOU crawl out of?
Memphis, TN| - http://www.thinkgeek.com
- Original Message -
From: "Josef Karthauser" [EMAIL PROTECTED]
To: "Soren Schmidt" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, January 02, 2001 10:15 AM
Subject: Re: Reprobing the ATAPI bus.
On Tue, Jan 02, 2001 at 03:50:34PM +0100, Soren Schmidt wrote:
It seems Josef Karthauser wrote:
Does anyone know how to reprobe the ATAPI bus, e.g. for a cd rom drive
in a laptop that wasn't present during boot?
Yes :)
Most of the code is already in the ATA driver, but the ioctl's and
the atacontrol program is still only here in my lab due to lack
of time...
I hope to be able to devote enough time to this soon, I'm currently
looking into having some of my time for this being sponsored...
I'll sponser you. How about a penny per line of code :).
I'll just reboot then whilst I wait ;p
Thanks,
Joe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
On Tue, Jan 02, 2001 at 10:22:02AM -0600, Daryl Chance wrote:
That could look/get ugly.
if
(
retval
==
-1
)
{
// blah
}
hehe ;P
He only gets paid if it conforms to style(9) Heh :b.
Joe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP question.
Félix-Antoine Paradis wrote: Hi, When we do a "dmesg" on a 4.2-STABLE box, we get: arp: 200.42.126.18 moved from 00:e0:7d:7b:53:f0 to 00:c0:df:f4:ac:05 on ed0 This means exactly what is says: IP address 200.42.126.18 was originally associated with ethernet MAC address ...:53:f0, but has moved to ...:ac:05. and, in ifconfig, it says: ed0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 200.42.126.20 netmask 0xff00 broadcast 200.42.126.255 inet6 fe80::2e0:7dff:fe7b:548a%ed0 prefixlen 64 scopeid 0x1 ether 00:e0:7d:7b:54:8a ed0 is connected to a switch. we want to know what the "arp: " message means. on the linux box, we have: eth0 Link encap:Ethernet HWaddr 00:C0:DF:F4:AC:05 inet addr:200.42.126.18 Bcast:200.42.126.23 Mask:255.255.255.248 Yes, this interface is now showing what ARP reported above. eth1 Link encap:Ethernet HWaddr 00:E0:7D:7B:53:F0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 And this one is not. Both eth0 and eth1 are connected to that same switch. Did the Linux box reboot when you got the ARP message? If so, the Linux box has reversed the order of the ethernet interfaces. If not, the Linux box is routing packets over the wrong interface, which can happen when you have two networks mingled together like this. What kind of switch is this? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
It seems Josef Karthauser wrote: He only gets paid if it conforms to style(9) Heh :b. Just forget about it then, and be patient :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 20:29 29/12/00 +0100, Marco van de Voort wrote:
Perfect for your purposes. I, as user (and with some machines
running on FreeBSD), want to be able to rebuild the kernel at any
time, and fix myself when needed. I don't want any binary packages
that can cause trouble and delay days.
before working for a com company, I'm a BSD user, and my participation to
this list is from this point of view.
I've never asked for any modifications that would make user's life harder.
note that I've not asked for any modifs, I just "started" the question.
You mean some base support in makefiles to make patching easier?
In general: No problem with that.
well, I was meaning a patch to config and to some makefiles.
why config?
I find it annoying that config must be run in $arch/conf, with the exact config
filename, and that either one has to be root or he has to copy kernel sources.
the config program requires that you run it in ${sys}/$arch/conf and that
you give
it a "pure" filename. "config /sys/i386/conf/GENERIC" doesn't work!
This is because it needs three dirs: the ${sys}/$arch/conf, the ${sys}/conf and
the ${sys}/compile. but I still believe this is an old heritage that may be
easily
"fixed".
In specific cases: No.
As a BSD user, I'll never ask for specific stuff, be it for a company I
work for:)
my discussion was about how to ease 3d party stuff in BSD, not how to
make any company or anybody happy by any sacrificial modifs.
The problem I was talking about is that if every company modifies the
kernel sources
or the build procedure in its own way, then the least of the things that
happen is that
the modifications are not compatible, which is not good.
now, let's forget about companies and about any commercial entities.
There are things to improve in BSD (though it's perfect:). and among those,
the possibility for extensibility, be it by single developpers, by
commercial companies,
or by anyone on earth.
The question is not who does what, the real question is how anything is done.
if that is good, it's good and we oughtta take it. if it's bad, we'd better
reject it.
cheers,
mouss
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Problems with FreeBSD 4.2
Hi, I installed FreeBSD 4.2 on my home PC last week and everything installed fine except for the desktop managers. When I tried to install KDE, I got the following errors: Add of package xpm-3.4k aborted, error code 1- Please check the debug screen for more info acd0: READ_BIG_MEDIUM ERROR asc=11 ascq=05 error=00 Loading of dependant package xpm-3.4k failed Loading of dependant package kdebase -1.1.2.1 failed In fact, I got these errors when trying to install any of the desktop managers. Could I have received a bad copy (on CD) of FreeBSD 4.2? Would it be possible to use /stand/sysinstall and load KDE from my old 3.4 CD ROM set? Any info would be appreciated. Thanks Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
On Tue, Jan 02, 2001 at 05:54:34PM +0100, Soren Schmidt wrote: It seems Josef Karthauser wrote: He only gets paid if it conforms to style(9) Heh :b. Just forget about it then, and be patient :) Oh go on then :) I'll pay you anyway :). Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP question.
At 09:47 01-01-02 -0700, you wrote: Félix-Antoine Paradis wrote: Hi, When we do a "dmesg" on a 4.2-STABLE box, we get: arp: 200.42.126.18 moved from 00:e0:7d:7b:53:f0 to 00:c0:df:f4:ac:05 on ed0 This means exactly what is says: IP address 200.42.126.18 was originally associated with ethernet MAC address ...:53:f0, but has moved to ...:ac:05. and, in ifconfig, it says: ed0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 200.42.126.20 netmask 0xff00 broadcast 200.42.126.255 inet6 fe80::2e0:7dff:fe7b:548a%ed0 prefixlen 64 scopeid 0x1 ether 00:e0:7d:7b:54:8a ed0 is connected to a switch. we want to know what the "arp: " message means. on the linux box, we have: eth0 Link encap:Ethernet HWaddr 00:C0:DF:F4:AC:05 inet addr:200.42.126.18 Bcast:200.42.126.23 Mask:255.255.255.248 Yes, this interface is now showing what ARP reported above. eth1 Link encap:Ethernet HWaddr 00:E0:7D:7B:53:F0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 And this one is not. Both eth0 and eth1 are connected to that same switch. Did the Linux box reboot when you got the ARP message? If so, the Linux box has reversed the order of the ethernet interfaces. If not, the Linux box is routing packets over the wrong interface, which can happen when you have two networks mingled together like this. What kind of switch is this? It is a Catalyst 2900 XL Series -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel debugging suggestion needed
I have written a KLD and am debugging it. The program often hangs after runs for a while (I guess it enters into some dead loop). Is there a way to attach to the process and somehow find out which code it is executing (with remote debugging or ddb)? Thanks for your help. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with sf driver?
I administer a box running v4.2-stable with a pair of the Adaptec ANA-62044 64-bit PCI, Quad port ethernet adapters. Six of the eight ethernet ports are in use. The box routes traffic between five private networks and provides NAT services out the public world on the sixth interface. I encounter an intermittant problem where one of the ports on a private network will quit functioning (usually sf2 or sf3). Nothing on that segment can reach the machine and if I try to ping something on that segment from the box in question I get: ping: sendto: No buffer space available The other five ports in use on the system continue to function normally. If I "ifconfig sfX down/up" the problem goes away. I've seen the problem as often as twice a day and sometimes gone a month without seeing it. The private segments carry very heavy SMB traffic. I have upped NMBCLUSTERS to 8192 with no success. Influenced by what I found digging though the DejaNews archives, I have also increased maxusers from 32 to 128, but do not believe the box has been up long enough to see if this has made a difference or not. Since these settings are global to the OS and I'm only encountering a problem with one port at a time, while the others continue to function normally, I have doubts they are an issue and suspect is must be a problem with the sf driver itself. I have swapped-out the NICs, the PC, and encountered the same problem with v3.x-stable. Thanks for any help you might offer. Below I'll paste some pertinate system configuration info. -G /* Glen R. J. Neff [EMAIL PROTECTED] 919-248-6145 Dirty deeds done for a meager 20% markup. . . */ uname -a output: FreeBSD squeakyfromme.rtp.dg.com 4.2-STABLE FreeBSD 4.2-STABLE #1: Tue Jan 2 11:36:03 EST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/squeakyfromme i386 Kernel config file: machine i386 # cpu I386_CPU # cpu I486_CPU # cpu I586_CPU cpu I686_CPU ident squeakyfromme maxusers128 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols # options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking # options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem # options MD_ROOT #MD is a potential root device options NFS #Network Filesystem # options NFS_ROOT#NFS usable as root device, NFS required # options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem # options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] # options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Added to to TX buffer problems with so many NICs. options NMBCLUSTERS=8192 # Required for NATd to function options IPFIREWALL options IPDIVERT # Required for port fowarding? # options IPFILTER # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa # deviceeisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # devicefd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0at isa? port IO_WD1 irq 14 device ata1at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives # deviceatapifd # ATAPI floppy drives # deviceatapist # ATAPI tape drives options
Re: Problems with sf driver?
* [EMAIL PROTECTED] [EMAIL PROTECTED] [010102 10:17] wrote: I administer a box running v4.2-stable with a pair of the Adaptec ANA-62044 64-bit PCI, Quad port ethernet adapters. Six of the eight ethernet ports are in use. The box routes traffic between five private networks and provides NAT services out the public world on the sixth interface. I encounter an intermittant problem where one of the ports on a private network will quit functioning (usually sf2 or sf3). Nothing on that segment can reach the machine and if I try to ping something on that segment from the box in question I get: ping: sendto: No buffer space available Can you show us the output of netstat -m after an incident? If your peak == max, then you actually are running out of bufferspace and should further raise maxusers/nmbclusters. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
On Sat, 30 Dec 2000, Nick Hibma wrote: The panic is definitely bad. It happens straight after failing the attach? Yep, but only during the kernel boot. Hot plugging the device after the system is booted spews the same errors to the console but does not cause a panic: uhid0: no report descriptor device_probe_and_attach: uhid0 attach returned 6 plug the device in again, and after it has panicked (it will drop into the debugger), type trace. That would give me a hint at where it crashes. Here you go. If you need anything else, please ask. kernel: type 12 trap, code=0 Stopped at DEVICE_PROBE+0xe: cmpl0(%edx),%eax db trace DEVICE_PROBE(c1142d00,c1142d00,c1139100,0,0) at DEVICE_PROBE+0xe device_probe_child(c1139100,c1142d00,c1142e00,0,c1142e30) at device_probe_child+0xc1 device_probe_and_attach(c1142d00) at device_probe_and_attach+0x29 usbd_probe_and_attach(c1139100,c1142e00,2,3,c1142e00) at usbd_probe_and_attach+0xef usbd_new_device(c1139100,c113a000,1,200,2,c11390c0) at usbd_new_device+0x1dd uhub_explore(c1139280,c1139300,c1139e80,0,c0456e64) at uhub_explore+0x1d4 usb_attach(c1139300,c0456e7c,c01afc0b,c1139300,c113a000) at usb_attach+0xf1 DEVICE_ATTACH(c1139300,c113a000,c1139e80,0,c0456ea0) at DEVICE_ATTACH+0x2e device_probe_and_attach(c1139300) at device_probe_and_attach+0x4f uhci_pci_attach(c1139e80,c0456ec4,c01afc0b,c1139e80,c1139e80) at uhci_pci_attach+0x33f DEVICE_ATTACH(c1139e80,c1139e80,c1136400,0,c0456ed4) at DEVICE_ATTACH+0x2e device_probe_and_attach(c1139e80) at device_probe_and_attach+0x4f bus_generic_attach(c1136380,c0456ef8,c01afc0b,c1136380,c1136380) at bus_generic_attach+0x16 DEVICE_ATTACH(c1136380,c1136380,c1136580,0,c0456f08) at DEVICE_ATTACH+0x2e device_probe_and_attach(c1136380) at device_probe_and_attach+0x4f bus_generic_attach(c1136400,c0456f2c,c01afc0b,c1136400,c1136400) at bus_generic_attach+0x16 DEVICE_ATTACH(c1136400,c1136400,c0e25800,0,c0456f3c) at DEVICE_ATTACH+0x2e device_probe_and_attach(c1136400) at device_probe_and_attach+0x4f bus_generic_attach(c1136580,c1136580,c0456f58,c012740e,c1136580) at bus_generic_attach+0x16 nexus_attach(c1136580,c0456f70,c01afc0b,c1136580,c1136580) at nexus_attach+0xd DEVICE_ATTACH(c1136580,c1136580,c039a710,45b000,c0456f80) at DEVICE_ATTACH+0x2e device_probe_and_attach(c1136580) at device_probe_and_attach+0x4f root_bus_configure(c0e25800,c036d38c,0) at root_bus_configure+0x16 configure(0,454c00,45b000,0,c0126df4) at configure+0x33 mi_startup(c0456fb4,b0206,ffe,45b000,c01b42f9) at mi_startup+0x70 begin() at begin+0x4b The controller probably requires some work because a fake report descriptor is needed to make it possible for the uhid driver to talk to it. It does not provide any information on where the information for the buttons and axes is stored in the descriptor returned on the interrupt pipe. --- Jon Simola [EMAIL PROTECTED] | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc cr
On 02-Jan-01 Gerhard Sittig wrote: On Mon, Jan 01, 2001 at 18:06 -0800, Doug Barton wrote: Speaking only for myself, I don't think your proposed changes are a good idea, which is why I refrained from offering any suggestions on how you can test them. Your refusal(id?) has been the only response so far and it didn't sound very clear / determined / explained (sorry, I lack better words) to me. :) So I guess the wording I used "DST handling in cron" was not done luckily. Let me cite from the doc diff: I must've missed this the first time through. This looks ok to me, though I'm curious if the 3 hour window is tweakable either by a compile time knob or a run time command line switch? 3 hours for the default would be ok... -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OT: silence as an answer? (was: how to test out cron.c changes?)
In this message I use the pronoun "you" quite a lot. It does not refer to anyone specifically. It's generic. On 2 Jan 2001, at 12:52, Gerhard Sittig wrote: Silence as I see it is just a sign for "nobody answered", without a reason to see why. You are not alone in this regard. Silence is neither consent nor disagreement. But in my experience, people are more vocal if they disagree with you than if they disagree (i.e. if you're made a fundamental mistake or error in your proposal) Getting ignored is definitely a fine way of discouraging future contributions. For people new to the project, this is definitely a major disappointment. But more experienced people will realise that repeating a proposal after a couple of week of silence is sometimes necessary. Sometimes, the message is just missed in the traffic and the one or two people which might be crucial to your proposal may have simply not seen your original post. The experience will make me think twice next time if I'm in the mood of spending my resources in the will to help and contribute just to find myself sitting there ignored. Would I really feel like having this kind of conversation, I could as well open my fridge and talk to it ... :-| Gerhard: like you said, it's the holidays. Wait a bit. Many people may have unsubscribed or will simply delete the messages waiting for them when they return. In either case, it's worth trying again. Someone out there has an interest in what you're doing. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ FreshPorts - http://freshports.org/ NZ Broadband - http://unixathome.org/broadband/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD + Mylex DAC960 (RAID 1) + DEC Prioris HX 6000 Server will not recognize boot record for some reason
This machine is an Intel Pentium Pro based system, (not a DEC Alpha), it currently has one 200mhz 512K CPU, 196megs RAM, (4 x 32edo simms, 4 x 16edo simms), and two 4.5Gig SCSI disks in hot-swappable drive carriages configured using RAID 1 (mirrored), attached to a Mylex DAC960P/PD dual-channel controller. I have flashed the firmware of the controller card to 3.52, as reccomended during the dmesg prompts (the card initially had 3.51). The problem seems to be with booting, I have tried several installs; all seem to partition fine except for 'dangerously dedicated'. After an install using a 4.4Gig root, and an 80meg swap, (leaving 20megs un-partitioned at the end of the drive), the system will not boot. If I boot off of the installation floppies, I can mount/view the files on the drive. This leaves me thinking it's got to have something to do with FreeBSD's MBR. Having problems booting; the system installs to the mylex system drive fine, but when I reboot, I get the FreeBSD boot MGR, and it only beeps when I press F1 for FreeBSD. If I install using a normal boot record, the system reports 'No operating system found'. I'm thinking it may be an issue with the Mylex card, but I don't know for sure if the system's bios could cause this either. I cannot attempt to install the mylex card in another machine; as the drives attached to it are in a hot-swap carriage which is part of the system's chassis. On a hunch, I tried re-partitioning and installing MsDos; maybe the RAID configuration isn't bootable at all I figured; but it partitioned fine, and booted properly. I then tried installing NT, and now Linux. All three had no problems, and all three booted fine. Seeing as how the other O/S's all installed/worked fine; I'm assuming this is just a software issue. Maybe with the bios of the Raid controller, or maybe with the system bios, has anyone else run into similar problems? Am I just missing something blatenly obvious? Does FreeBSD not boot from a mirrored volume (if so... why not)? I've only ever done one other server install with FreeBSD, and a Mylex Raid controller; it booted fine. It was using an AcceleRAID PCI 150 card, with foud 9.1gig SCSIUW's in a RAID 5 configuration. It went fine with no hitches, (cept that it took like 1hr to newfs). However, this is a different controller, and having little to no experience working with RAID controllers I figured I'd ask. Baring no absolute solutions, or better partial ones from this mailing list, I'm going to install Linux on a 200meg partition, and attempt to install FreeBSD on the rest and boot it using Lilo (don't know if it's going to work...but it's worth a try). -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP question.
Some more fuel... On Tue, 2 Jan 2001, [iso-8859-1] Félix-Antoine Paradis wrote: Hi, When we do a "dmesg" on a 4.2-STABLE box, we get: arp: 200.42.126.18 moved from 00:e0:7d:7b:53:f0 to 00:c0:df:f4:ac:05 on ed0 From personal experience, Linux has this nasty bad habit of broadcasting ARPs on all interfaces. For this reason multihomed Linux boxes should be banned. We got tired of it at my previous job and patched around it on the linux machine. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
On Tue, 2 Jan 2001, Zhiui Zhang wrote: I have written a KLD and am debugging it. The program often hangs after runs for a while (I guess it enters into some dead loop). Is there a way to attach to the process and somehow find out which code it is executing (with remote debugging or ddb)? kld debugging is a bit tricky. Take a look at the debugging macros and bits that Greg Lehey put together for vinum for a starting point. You have to calculate the appropriate offset to get to the KLD code in gdb. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
[Sorry for lack of message in this reply but I accidently rm'd the original emails to reply to :-) ] One thing I've done in the past is if it's convenient in a section of code to hijack a function pointer in the kernel, then hijack it so that it will call your code... Silly, and not always really useful... But, Ive done it before *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BSD dlopen and such
Hi all, Two questions: 0) Are native binaries for OpenBSD different from FreeBSD? 1) Can a native binary dlopen a Linux ELF GL, yes or no? Rafael Barrero [EMAIL PROTECTED] "You know ... you take the killing for granted. And then it's gone, and you're like, 'I wish I'd appreciated it more.' Stopped and smelled the corpses, you know?" -Spike (BtVS) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
On Tuesday, 2 January 2001 at 14:03:16 -0800, Doug White wrote:
On Tue, 2 Jan 2001, Zhiui Zhang wrote:
I have written a KLD and am debugging it. The program often hangs after
runs for a while (I guess it enters into some dead loop). Is there a way
to attach to the process and somehow find out which code it is executing
(with remote debugging or ddb)?
kld debugging is a bit tricky. Take a look at the debugging macros and
bits that Greg Lehey put together for vinum for a starting point. You have
to calculate the appropriate offset to get to the KLD code in gdb.
Doug Rabson has described an alternative to me, but I never got it to
work. My hack walks down the list of klds looking for a name starting
with 'v'; you can change this to something which identifies your kld,
and you'll need to change the name of the kld itself, of course. I
also have a number of other macros in files in
/usr/src/sys/modules/vinum.
Here's the macro:
define asf
set $file = linker_files.tqh_first
set $found = 0
while ($found == 0)
if (*$file-filename == 'v')
set $found = 1
else
set $file = $file-link.tqe_next
end
end
shell /usr/bin/objdump --section-headers sys/modules/vinum/vinum.ko | grep ' .text'
| awk '{print "add-symbol-file sys/modules/vinum/vinum.ko \$file-address+0x" $4}'
.asf
source .asf
end
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD dlopen and such
Rafael Barrero [EMAIL PROTECTED] wrote: 0) Are native binaries for OpenBSD different from FreeBSD? Yes. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
help!
Hi. I have a netgear Ethernet card installed in my computer. In order to reconnect my computer to the internet, I have to reinstall the drivers and they're missing. So, I opened up my computer to look at the Ethernet card and I copied down the necessary numbers. However, I do not know how to download the program. I found this e-mail address on the web and would greatly appreciate some help. Thank you! -Christina, [EMAIL PROTECTED]
Re: kernel debugging suggestion needed
On Tue, 2 Jan 2001, Doug White wrote: On Tue, 2 Jan 2001, Zhiui Zhang wrote: I have written a KLD and am debugging it. The program often hangs after runs for a while (I guess it enters into some dead loop). Is there a way to attach to the process and somehow find out which code it is executing (with remote debugging or ddb)? kld debugging is a bit tricky. Take a look at the debugging macros and bits that Greg Lehey put together for vinum for a starting point. You have to calculate the appropriate offset to get to the KLD code in gdb. I already did this. I hope that I can find a way to know which process is running which part of the KLD code endlessly. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
On Tuesday, 2 January 2001 at 23:22:49 -0500, Zhiui Zhang wrote: On Tue, 2 Jan 2001, Doug White wrote: On Tue, 2 Jan 2001, Zhiui Zhang wrote: I have written a KLD and am debugging it. The program often hangs after runs for a while (I guess it enters into some dead loop). Is there a way to attach to the process and somehow find out which code it is executing (with remote debugging or ddb)? kld debugging is a bit tricky. Take a look at the debugging macros and bits that Greg Lehey put together for vinum for a starting point. You have to calculate the appropriate offset to get to the KLD code in gdb. I already did this. I hope that I can find a way to know which process is running which part of the KLD code endlessly. There are other macros in my .gdbinits which give you backtraces of other processes. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: Is there anyone out there who feels like rejecting the proposal for a *reason*? Or to accept the idea, but to redirect the effort to a "real solution"? I somehow doubt you'd rather explain again and again that cron(8) isn't broken but that users should shuffle around the daily job's execution time ... I'm opposed to the changes. Those people who live in places that use daylight savings time should be aware of its effect on their lives and should understand that scheduling events to fall during the missed or repeated time at the changeover (whether by cron or by any other mechanism) is going to produce anomalous results. Therefore, the /right/ thing to do is to avoid the times where this problem can occur. IMO, the solution is to put a note at the top of the distributed /etc/crontab file suggesting that people who have DST not put jobs in the transition times, together with similar notes in the relevant man pages and in comments at the top of the files that are generated by crontab. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
- Original Message - From: "James Halstead" [EMAIL PROTECTED] To: "Poul-Henning Kamp" [EMAIL PROTECTED] Sent: Tuesday, January 02, 2001 11:30 PM Subject: Re: Boot process robustness - Original Message - From: "Poul-Henning Kamp" [EMAIL PROTECTED] To: "Walter W. Hop" [EMAIL PROTECTED] Cc: "FreeBSD hackers" [EMAIL PROTECTED] Sent: Thursday, December 28, 2000 9:31 AM Subject: Re: Boot process robustness In message [EMAIL PROTECTED], "Walter W. Ho p" writes: Hi all, I was wondering how to increase the robustness of the booting process, so that a box would be able to keep itself on its feet without intervention of the console. I think this would be of great value to the many people who administer colocated boxes. I'm not much of a coder so all I can do is mailing this (at the risk of wasting your time with total useless crap ofcourse, in which case I apologize.) 1. Old kernel recovery When 'make install'ing a new kernel, a flag is raised (say, 'revert_on_fail') which is only cleared after a successful system initialisation. When the new kernel boots, a panic in this state or an unexpected reboot (reset after a system hang) would cause /kernel.old to be loaded on the next boot instead (maybe the same could work for /etc/rc.conf.old) This is actually more a question of where to store the flag than anything else. Couldn't you just modify the shutdown command to have an option for revert on fail, which would create a file on the root filesystem with a timestamp of when the reboot started. Then at boot time, if that timstamp is still there, and has been around for too long, boot the kernel.old instead of kernel. Then the question is what amount of time is reasonable for the wait period. This may have the machine boot the new kernel and panic a few times, but at least you can be assured that it would after x minutes boot the old kernel instead. Once a boot was successful the times stamp file could be removed. Just a thought. ~James Julian made a rather hackish thing for Whistle, but I think we lost that with the advent of the new bootblocks. 2. Automatic file system checks In case of a powercycle or crash, it could be that a filesystem needs fixing. Now I don't know much about fs internals, but I guess that in most cases just answering 'Y' to fsck's questions will fix things. I would appreciate an option where an inconsistency would start up fsck in an "automatic" repair mode, with all actions logged and "undo" data being saved (in case manual review is needed). Alternatively it might be worth considering adding a "remote-single-user" capability: If an fsck fails, ifconfig the interfaces and start an sshd so people can get in remotely and fsck... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARP question.
On Tue, Jan 02, 2001 at 02:02:03PM -0800, Doug White wrote: arp: 200.42.126.18 moved from 00:e0:7d:7b:53:f0 to 00:c0:df:f4:ac:05 on ed0 From personal experience, Linux has this nasty bad habit of broadcasting ARPs on all interfaces. For this reason multihomed Linux boxes should be banned. We got tired of it at my previous job and patched around it on the linux machine. I've seen similar things from Linux. In my experience it was an ARP who-has request with the source IP of the other interface. Linux apparently doesn't learn ARP addresses this way, but FreeBSD takes note, which causes the problem mentioned above. Is the Linux box a firewall/NAT box of some kind? Having two interfaces on the same wire can be a problem. FreeBSD's ARP implementation gets rather upset about seeing the packets twice, since the receive interface is significant. Broadcast protocols aren't guaranteed to be idempotent. Your mileage may vary. - Steve -- C. Stephen Gunn URL: http://www.waterspout.com/ WaterSpout Communications, Inc.Email: [EMAIL PROTECTED] 427 North 6th Street Phone: +1 765.742.6628 Lafayette, IN 47901 Fax: +1 765.742.0646 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
On Wed, Jan 03, 2001 at 02:38:30PM +1000, Greg Black scribbled: | Gerhard Sittig wrote: | Is there anyone out there who feels like rejecting the proposal | for a *reason*? Or to accept the idea, but to redirect the | effort to a "real solution"? I somehow doubt you'd rather | explain again and again that cron(8) isn't broken but that users | should shuffle around the daily job's execution time ... | | I'm opposed to the changes. Those people who live in places | that use daylight savings time should be aware of its effect on You see, "those people" equates to sysadmins living in North/South America, Europe, Australia, and some other places. | their lives and should understand that scheduling events to fall | during the missed or repeated time at the changeover (whether by | cron or by any other mechanism) is going to produce anomalous | results. Therefore, the /right/ thing to do is to avoid the | times where this problem can occur. | | IMO, the solution is to put a note at the top of the distributed | /etc/crontab file suggesting that people who have DST not put | jobs in the transition times, together with similar notes in the | relevant man pages and in comments at the top of the files that | are generated by crontab. Daylight savings time is here to stay. Nobody is going to change this for bunch of unix servers. I do not understand why people resist change in FreeBSD so much. This does not hurt anybody. Mr.Blacks' /etc/crontab comment idea is quite the thing that we try to avoid in the tree. -- Sigh, yet another bikeshed. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc cr
On Tue, Jan 02, 2001 at 11:36 -0800, John Baldwin wrote:
[ manpage diff for cron.c change reasoning ]
I must've missed this the first time through.
I hoped that silence is not always meant in a negativ way. :
See my first message to freebsd-hackers as of December 5th at
http://www.freebsd.org/cgi/getmsg.cgi?fetch=211030+217815+/usr/local/www/db/text/2000/freebsd-hackers/20001210.freebsd-hackers
This looks ok to me, though I'm curious if the 3 hour window is
tweakable either by a compile time knob or a run time command
line switch? 3 hours for the default would be ok...
The code is taken verbosely from the FreeBSD - OpenBSD diff of
cron (modulo capability / gcc / other unrelated patches the
OpenBSD version has, but both are based on vixie cron). The
decision you refer to looks like this:
+ wakeupKind = -1;
+ if (timeDiff -(3*MINUTE_COUNT))
+ wakeupKind = 0;
+ if (timeDiff 0)
+ wakeupKind = 1;
+ if (timeDiff 5)
+ wakeupKind = 2;
+ if (timeDiff (3*MINUTE_COUNT))
+ wakeupKind = 3;
+
+ switch (wakeupKind) {
The "three times the minutes one hour has" could easily be made
tweakable as soon as there's someone who knows how to propagate a
compile time option into a *.c file. :) I'm not clear where to
put this thing: /usr/src/usr.sbin/cron/Makefile, some header
file, cron.c beginning, ...?
Well, the trigger level probably should live in a public
variable, get initialized with a #define'd value (tweakable in
the Makefile) and overridden at argv[] parse time. This should
give all the benefits of leaving it alone, editing source before
compile time as well as providing an argument at run time. But
let's wait with this until the feature is worth at all to make it
into FreeBSD. :) Unless this decision depends on the possibility
to tweak the trigger level ... :
I guess I will have to roll the current state (stuck since early
December when the silence started:) into a PR to have a base for
further discussions and most of all review. There are chances I
did something stupid (cut the diff too much / too little) and
there's room for improvement (like your turnable knob as well as
making the above operate on "more readable" enums and the like).
Give me a few days to sort my stuff. Although I didn't want to
bother you with (functionally) untested patches, I fail to see
any other way of making possible progress in this special
feature's case -- discussions would be too much in theory without
the patch getting published. Unless somebody could tell me how
to test it here locally -- to save other peoples' time by not
publishing unfinished code ...
BTW: Thank you for CC'ing me. Otherwise there would be turn
around times of some five days when I had to follow the thread
via the web interface. :)
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
TCP Rate-Halving
[If need be, please add Cc: to -net] While doing my own research project, I came across this piece of information. It seems like a "nobody-has-it-but-it-is-fast" thing. http://www.psc.edu/networking/ftp/papers/draft-ratehalving.txt It seeks to improve the Reno TCP implementation by the most recommended trick in the book, redesigning the algorithm. From the above url: "Hoe [Hoe95] suggested that during Fast Recovery the TCP data sender space out retransmissions and new data on alternate acknowledgements across the entire recovery RTT. (Note that this eliminates the half RTT lull in sending which occurs in Reno TCP.)" Do we already do this? I know that a re-write of our TCP code is "imminent." This seeks to improve congested server TCP connections. (Oh BTW, Isn't TCP the little thing that servers use ;-)? ) Will someone enlighten me on how deviated we are from the Reno TCP code? I am under the impression that we have the W. Stevens RFC2581 implemented. Is that true? They even implemented this for NetBSD and DECUnix/Tru64: http://www.psc.edu/networking/tcp.html#psc Is this specified in the IPv6 specs? Does KAME do this? If this has already been implemented, can someone e And perhaps we can implement/import this...someday, like what we did with schedular activations. Relevant: http://www.psc.edu/networking/rate-halving/ RFC2581 RFC2481 -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP Rate-Halving
Is this specified in the IPv6 specs? Does KAME do this? I don't think so. TCP on IPv6 is exactly the same as TCP on IPv4. only differences I know of are in the following portion: (1) pseudo-header checksum documented in in RFC2460 section 8.1 (2) jumbogram support documented in RFC2675 there's no additional requirements whatsoever, I believe. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
