Re: isp driver not 64 bit?
In the last episode (Nov 29), David Gilbert said: > Well... cam_calc_geometry seems to get called quite a bit. Almost > everytime you touch the disk, in fact. fsck'ing a partition calls > it, for instance. > > Console access is personally expensive (much driving, for instance), > but from memory the debugging I put in cam_calc_geometry() would > print before the correct output from dadone(). Your description > reminds me of this --- but it's no less vexing that the output from > dadone() has the correct sector and volume size and the ccg in > cam_calc_geometry() has bogus data. > > I don't know if it's significant, but the correct numbers were: > > 279353684 sectors of 512 bytes > > The ccg structure comes up with: > > 3737169375 sectors of 3737169374 bytes > > Not entirely sensible. Interesting that they're close values. > However, with different things on the stack, the values changed. Even more interesting is their hex values: DEC0ADDF and DEC0ADDE, aka 0xDEADC0DE. Something's reading memory after the kernel freed it. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A hack to rebuild port KLDs during kernel builds
On Tue, 30 Nov 2004 15:58, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > : On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote: > : > Can't you just add modules override with absolute path name? > : > : I don't think so, because.. > > MODULES_OVERRIDE is different. It can take a list of paths to > upgrade. Ahh I see. Hmm, that could work but I think it fits in better with the kernel build if you can treat port installed modules just like their base counterparts. > : If you already have the port installed it will barf unless you set > : FORCE_PKG_REGISTER. > > That's just a minor bug I've not yet fixed. minor? :) > : Also, it would force an upgrade of the port which isn't necessarily > : a good thing (eg I can't use the latest nvidia port because the 6113 > : driver blows up on my laptop). > > That's up to the user to manage :-( How though? I think it makes much more sense to install the source code you know works so rebuilding your kernel doesn't need distfiles (which might require net access) or potentially forcing a port to be upgraded from something you know works. -- 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 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp9vR7oaft10.pgp Description: PGP signature
Re: A hack to rebuild port KLDs during kernel builds
In message: <[EMAIL PROTECTED]> "Daniel O'Connor" <[EMAIL PROTECTED]> writes: : On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote: : > Can't you just add modules override with absolute path name? : : I don't think so, because.. MODULES_OVERRIDE is different. It can take a list of paths to upgrade. : On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote: : > Any chance you can use the recently added PORTS_MODULES knob to do what : > you want? : : Hmm.. I don't really see how that can work actually.. : If you already have the port installed it will barf unless you set : FORCE_PKG_REGISTER. That's just a minor bug I've not yet fixed. : Also, it would force an upgrade of the port which isn't necessarily : a good thing (eg I can't use the latest nvidia port because the 6113 : driver blows up on my laptop). That's up to the user to manage :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsdtar needs --ignore-zero & --ignore-failed-read
Andrew Sinclair wrote: I found this out when attempting to extract an archive from a CD-RW. It had a few bad blocks ... I was able to work around it with gtar and the --ignore-zero and --ignore-failed-read options but I could not find an equivalent solution for bsdtar. My suggestion is to include these options in libarchive and to assert --ignore-zero in bsdtar by default on plain files ... Thanks for the suggestion; I'll see about adding these. I am reluctant to assert these by default, however. Not because I expect anyone to deliberately append anything, but because I expect there to be tar archivers that append garbage to fill out the final block. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A hack to rebuild port KLDs during kernel builds
On Tue, 30 Nov 2004 14:35, M. Warner Losh wrote: > Can't you just add modules override with absolute path name? I don't think so, because.. On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote: > Any chance you can use the recently added PORTS_MODULES knob to do what > you want? Hmm.. I don't really see how that can work actually.. If you already have the port installed it will barf unless you set FORCE_PKG_REGISTER. Also, it would force an upgrade of the port which isn't necessarily a good thing (eg I can't use the latest nvidia port because the 6113 driver blows up on my laptop). -- 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 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgppCrmLhFwQA.pgp Description: PGP signature
Re: A hack to rebuild port KLDs during kernel builds
Can't you just add modules override with absolute path name? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: isp driver not 64 bit?
> "Matt" == Matt Emmerton <[EMAIL PROTECTED]> writes: Matt> You indicate that this probe is done properly. >> From what I see, cam_calc_geometry() is called *before* the device >> probe Matt> prints out the device size, so I'm unsure of how what you are Matt> describing can occur. Well... cam_calc_geometry seems to get called quite a bit. Almost everytime you touch the disk, in fact. fsck'ing a partition calls it, for instance. Console access is personally expensive (much driving, for instance), but from memory the debugging I put in cam_calc_geometry() would print before the correct output from dadone(). Your description reminds me of this --- but it's no less vexing that the output from dadone() has the correct sector and volume size and the ccg in cam_calc_geometry() has bogus data. I don't know if it's significant, but the correct numbers were: 279353684 sectors of 512 bytes The ccg structure comes up with: 3737169375 sectors of 3737169374 bytes Not entirely sensible. Interesting that they're close values. However, with different things on the stack, the values changed. Matt> Have you built & run a kernel compiled with "options CAMDEBUG" ? Matt> This may provide more insight into where things are going wrong. I put CAMDEBUG in the kernel, but it didn't seem to change the output that much. It seemed to dump the control block showing when geom tried to access the high block number --- and failed, but nothing else particularly useful. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: isp driver not 64 bit?
Dave, > After a bunch of frustrating debugging, I've tenatively come to the > conclusion that the isp(4) driver is not 64 bit safe --- at the very > least insofar as the amd64 platform is concerned. > > The test setup was a quad opteron 248 system connected via two isp > 2340 cards to switches which interconnect to an EMC^2 disk array. > I've made a couple of interim posts on this subject. > > The message from scsi_da.c indicates the correct probe is received > from the disk. In the test, it was a 131 gig disk of 512 byte > sectors. However, by the time we get to cam_calc_geometry() in > cam.c, the structure is corrupt --- containing bad values for both > volume_size and sector_size. Here's what I found by walking through the code. Mind you, given that I'm no expert on this code either, I may be missing things. 1) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 probes the device for capacity information. 2) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then calls dasetgeom(). The parameters to dasetgeom() are obtained from 1), are updated in softc->params and later the ccg. All variables involved in these assignments have matching types, so there should be no truncation. 3) dasetgeom() then calls xpt_action() [ which I'm assuming is redirected to dev/isp/isp_freebsd.c::isp_action() ] with a function id of XPT_CALC_GEOMETRY, which ultimately calls cam_calc_geometry(). 4) cam/scsi/scsi_da.c::dadone() function DA_CCB_PROBE2 then prints out a probe of the device size. You indicate that this probe is done properly. >From what I see, cam_calc_geometry() is called *before* the device probe prints out the device size, so I'm unsure of how what you are describing can occur. Have you built & run a kernel compiled with "options CAMDEBUG" ? This may provide more insight into where things are going wrong. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
isp driver not 64 bit?
After a bunch of frustrating debugging, I've tenatively come to the conclusion that the isp(4) driver is not 64 bit safe --- at the very least insofar as the amd64 platform is concerned. The test setup was a quad opteron 248 system connected via two isp 2340 cards to switches which interconnect to an EMC^2 disk array. I've made a couple of interim posts on this subject. The message from scsi_da.c indicates the correct probe is received from the disk. In the test, it was a 131 gig disk of 512 byte sectors. However, by the time we get to cam_calc_geometry() in cam.c, the structure is corrupt --- containing bad values for both volume_size and sector_size. The data is bogus enough at this point, that it can't be repaired ... and I gave up on the "quick fix" effort. Origionally, it manifested as a divide by zero error (the block size was so huge, it brought the denominator in the first few lines to zero). But both the block_size and the volume_size are bogus making efforts by geom to taste the last sector fail. The isp driver is quite complex. I havn't encountered much of the SCSI or CAM stack before. It would seem a brief overview of where things go from the momment when scsi_da prints out the correct size to the point at which cam_calc_geometry() receives corrupt data would help greately. Our hardware vendor is going to try to obtain test hardware for the LSI logic HBA and an Adaptec HBA --- so we can test them. The test machine remains somewhat available, but it looks like the production machines will be linux (unless I can solve this problem this week). Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A hack to rebuild port KLDs during kernel builds
On Mon, 29 Nov 2004 23:08, Ruslan Ermilov wrote: > > Note that (obviously) the ports need to be tweaked to install the driver > > source and build infrastructure there, but that's not too hard (to do by > > hand for now anyway). I have the 4 I mentioned building just fine with 5 > > minutes work. > > Any chance you can use the recently added PORTS_MODULES knob to do what > you want? Hmm.. I don't really see how that can work actually.. If you already have the port installed it will barf unless you set FORCE_PKG_REGISTER. Also, it would force an upgrade of the port which isn't necessarily a good thing (eg I can't use the latest nvidia port because the 6113 driver blows up on my laptop). -- 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 GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpRlZM5OGtdT.pgp Description: PGP signature
Re: Hand on gmirror (Was: Re: gmirror bugs, how many?)
On Mon, Nov 29, 2004 at 07:27:51PM -0200, Jo?o Carlos Mendes Luís wrote: +> I finally got the system to boot with gmirror fully enabled. But I got +> this during boot: +> +> +> GEOM_MIRROR: Device vol0 created (id=3592859320). +> GEOM_MIRROR: Device vol0: provider ad0s1 detected. +> GEOM_MIRROR: Device vol0: provider ad1s1 detected. +> GEOM_MIRROR: Device vol0: provider ad1s1 activated. +> GEOM_MIRROR: Cannot update metadata on disk ad0s1 (error=1). +> GEOM_MIRROR: Device vol0: provider ad0s1 activated. +> GEOM_MIRROR: Device vol0: provider mirror/vol0 launched. +> GEOM_MIRROR: Cannot update metadata on disk ad0s1 (error=1). +> GEOM_MIRROR: Device vol0: provider ad0s1 disconnected. This is known race, which is already fixed in HEAD. I want to commit it soon. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgpoTcPvSZWCS.pgp Description: PGP signature
Re: HD Mirroring
On Mon, 2004-11-29 at 12:24, Andre Oppermann wrote: ...(snip)... > > Perhaps somebody else can do a more thorough test of MySQL clustering on > > FreeBSD to make sure that it is in fact fully stable. It seems like a > > remarkable system, assuming you have the gigs of RAM it takes to run it > > with a table of any substantial size... > > But that is an application problem, not FreeBSD's fault. I certainly did not mean to imply that this was a problem with FreeBSD, nor even a problem in MySQL Cluster, I simply meant that the RAM requirements for MySQL Cluster are higher than one might guess. -- Justin Hopper <[EMAIL PROTECTED]> UNIX Systems Engineer BSDHosting.net Hosting Division of Digital Oasys Inc. http://www.bsdhosting.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hand on gmirror (Was: Re: gmirror bugs, how many?)
I finally got the system to boot with gmirror fully enabled. But I got this during boot: GEOM_MIRROR: Device vol0 created (id=3592859320). GEOM_MIRROR: Device vol0: provider ad0s1 detected. GEOM_MIRROR: Device vol0: provider ad1s1 detected. GEOM_MIRROR: Device vol0: provider ad1s1 activated. GEOM_MIRROR: Cannot update metadata on disk ad0s1 (error=1). GEOM_MIRROR: Device vol0: provider ad0s1 activated. GEOM_MIRROR: Device vol0: provider mirror/vol0 launched. GEOM_MIRROR: Cannot update metadata on disk ad0s1 (error=1). GEOM_MIRROR: Device vol0: provider ad0s1 disconnected. Both slices have been created with a cylinder less than the maximum, to avoid having to use hardcoded names. The last messages before the shutdown -r were: Nov 29 15:03:56 sigesc kernel: GEOM: Configure ad0s1a, start 0 length 536870912 end 536870911 Nov 29 15:03:56 sigesc kernel: GEOM: Configure ad0s1b, start 536870912 length 536870912 end 1073741823 Nov 29 15:03:56 sigesc kernel: GEOM: Configure ad0s1c, start 0 length 8447394304 end 8447394303 Nov 29 15:03:56 sigesc kernel: GEOM: Configure ad0s1d, start 1073741824 length 7373652480 end 8447394303 Nov 29 15:04:16 sigesc kernel: GEOM_MIRROR: Device vol0: provider ad0s1 detected. Nov 29 15:04:16 sigesc kernel: GEOM_MIRROR: Device vol0: rebuilding provider ad0s1. Nov 29 15:35:19 sigesc kernel: GEOM_MIRROR: Device vol0: rebuilding provider ad0s1 finished. Nov 29 15:35:19 sigesc kernel: GEOM_MIRROR: Device vol0: provider ad0s1 activated. Nov 29 15:35:19 sigesc kernel: GEOM: Configure ad0s1a, start 0 length 536870912 end 536870911 Nov 29 15:35:19 sigesc kernel: GEOM: Configure ad0s1b, start 536870912 length 536870912 end 1073741823 Nov 29 15:35:19 sigesc kernel: GEOM: Configure ad0s1c, start 0 length 8447394304 end 8447394303 Nov 29 15:35:19 sigesc kernel: GEOM: Configure ad0s1d, start 1073741824 length 7373652480 end 8447394303 I thought the syncronization was completed without errors. What have I missed? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh & select() problem on 5.3
Peter Jeremy wrote: On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote: Since the problem occurs only when I connect to the firewall or to a server behind it, I started to suspect a hardware failure. Could a network card cause such problems ? A couple of people have mentioned path-MTU problems. I've also bumped into this problem when playing with VLANs where one end of the VLAN trunk doesn't support long frames - an oversize packet will get ignored by the receiver without any error being returned. It seems that packets of size more then 1478 are dropped somewhere, but not on the FreeBSD Firewall. The problem seems to be that it never receives a ICMP "fragmentation needed but DF set". Unfortunately I have control only over the firewall and what's behind it. Next after the firewall (towards internet) there are a switch and a Cisco router. I asked about the settings of this two, and it seems that the switch is used for VLANs, and the Cisco for making a tunnel over fiber channel with the next hop. I have too few information about this at the moment, but I am almost certain that the problems are occuring because of the Cisco router. I did a traceroute from the firewall to outside, and big packets always stop on Cisco router. A traceroute from outside to the firewall always stops at the hop exactly before the cisco router I am talking about, which I suppose is the other end of this tunnel. -- Claudiu Dragalina-Paraipan [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: ssh & select() problem on 5.3
Andre Oppermann wrote: Peter Jeremy wrote: On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote: Since the problem occurs only when I connect to the firewall or to a server behind it, I started to suspect a hardware failure. Could a network card cause such problems ? A couple of people have mentioned path-MTU problems. I've also bumped into this problem when playing with VLANs where one end of the VLAN trunk doesn't support long frames - an oversize packet will get ignored by the receiver without any error being returned. If the oversized ethernet frame makes it to the FreeBSD box it will drop the frame in the ethernet hardware or in ether_input() with a message. If you don't get a message on the console you have to look at the driver statistics if it got any oversized frames. If the switches along the patch can't handle the oversized frame they will simply drop it. No way to work around that. When the MTU is set to a value below 1500, for example 1450, I get this messages: Nov 29 23:02:34 firewall kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1466 > max 1464) Nov 29 23:03:00 firewall kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 > max 1464) ... and much many of them. With MTU 1500 I didn't notice any such message in logs. So, can I safely assume that the problem occurs because somewhere packets are simply dropped, without any warning ? -- Claudiu Dragalina-Paraipan [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: HD Mirroring
Justin Hopper wrote: On Wed, 2004-11-24 at 23:08, Justin Hopper wrote: On Wed, 2004-11-24 at 13:31, Charles Sprickman wrote: On Wed, 24 Nov 2004, Brian Reichert wrote: And, although I've not tested it, recent versions of MySQL can outright support a cluster: http://dev.mysql.com/doc/mysql/en/NDBCluster.html I'm just curious if there's any other solution that will work on FreeBSD. I have about 5 mysql servers (4 slaves, 1 master) and one application in particular is not smart enough to try other servers if the configured server does not answer. Is there any type of local proxy that can intelligently route requests to the "best" server? I too was curious about the MySQL Clustering support and its status on FreeBSD, since it wasn't as a supported OS. Over the last couple of hours I was able to set up a cluster consisting of a management process and data node running in one jail, and a MySQL server and another data node running in a different jail. Once everything was up and running, the cluster seemed to be working excellent, data was synchronizing flawlessly throughout the cluster. Nuking either of the data node processes did not affect access to the data in the cluster, so failover seemed to be working as well. The only problem that I ran into, and it may be user error on my part, is that when the cluster is shut down (or all data node processes are killed), the data contained in the node is lost when the cluster is brought back online. Perhaps there is some recovery step that is required before the cluster can be used again. If someone else has already tested MySQL's clustering ability with FreeBSD, then please let us know the results so that I don't recreate the wheel here. If not, I'll continue seeing how far I can get with it, as I would definitely like to implement this functionality on several of the more critical databases that I manage. I'm sure it's taboo to respond to one's own message, but thought I would follow up with some information on the problems I was running into with MySQL Cluster. The first problem, where it appeared that the data in the cluster was lost when the cluster was shut down, turned out to be there are some problems with the MySQL servers, which act as API clients to the cluster, reliably connecting into the cluster. Several times I could not get a MySQL server to connect to the cluster, but found no rhyme or reason for it so far. The cluster seems to be retaining data just fine upon shutdown, when the MySQL servers can actually connect to it to query data that is... If you have many TCP connections to one target it may happen that you get the same source port on the originator again within the TIME_WAIT timeout. And if the ISN wrapped in the meantime the new connection will 'hang'. The second problem I encountered was while trying to load a table that was 163MB in size that contained around 1 million rows. The NDB cluster would continually report that the table was "full" when trying to import the data. After checking around on mailing lists, I found out that the NDB clustering engine will require around table_size*2*10% RAM to load a table. NDB keeps all of the data in main memory, and has a fair amount of overhead per row. Perhaps somebody else can do a more thorough test of MySQL clustering on FreeBSD to make sure that it is in fact fully stable. It seems like a remarkable system, assuming you have the gigs of RAM it takes to run it with a table of any substantial size... But that is an application problem, not FreeBSD's fault. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh & select() problem on 5.3
Peter Jeremy wrote: On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote: Since the problem occurs only when I connect to the firewall or to a server behind it, I started to suspect a hardware failure. Could a network card cause such problems ? A couple of people have mentioned path-MTU problems. I've also bumped into this problem when playing with VLANs where one end of the VLAN trunk doesn't support long frames - an oversize packet will get ignored by the receiver without any error being returned. If the oversized ethernet frame makes it to the FreeBSD box it will drop the frame in the ethernet hardware or in ether_input() with a message. If you don't get a message on the console you have to look at the driver statistics if it got any oversized frames. If the switches along the patch can't handle the oversized frame they will simply drop it. No way to work around that. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
path to cam_calc_geometry?
I have a situation where the drive probe prints out the correct size information for the drive, but the sectors and blocksize information passed to cam_calc_geometry is bogus. This is on an amd64 system with the isp driver. What is the path between these? Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ntpd question
Configuration: 5.3-STABLE. I have 2 DHCP interfaces (a bit strange,
but it does not matter). Right after dhclient i have the next situation:
em0: flags=8843 mtu 1500
options=1b
inet 192.168.0.114 netmask 0xff00 broadcast 192.168.0.255
ether 00:e0:81:61:1b:fd
media: Ethernet autoselect (100baseTX )
status: active
lo0: flags=8049 mtu 16384
inet 127.0.0.1 netmask 0xff00
rue0: flags=108843 mtu 1500
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
ether 00:10:60:e9:33:2c
media: Ethernet autoselect (none)
status: no carrier
Note that rue0 has address 0.0.0.0
Now i'd like to sync time on the box using ntpd -q, and i got
--- quote
Nov 29 21:08:09 pbxbox ntpd[71729]: ntpd 4.2.0-a Wed Oct 20 14:36:02
EEST 2004 (1)
Nov 29 21:08:09 pbxbox ntpd[71729]: no IPv6 interfaces found
Nov 29 21:08:09 pbxbox ntpd[71729]: bind() fd 7, family 2, port 123,
addr 0.0.0.0, in_classd=0 flags=8 fails: Address already in use
Nov 29 21:08:27 pbxbox ntpd[71729]: no reply; clock not set
--- /quote
I've made some research and found the source of problem. It is in
ntp_io.c See lines 522-526. They blacklist addresses of local
interfaces.
But hack_restrict has this code fo find restrictions list
entry(ntp_restrict:327):
if (addr == 0) {
rlprev = 0;
rl = restrictlist;
} else {
it finds first entry of list (0.0.0.0/0.0.0.0) and marks it as
blacklisted. Theis means we restrict all packets. I think the fix will
be
if ((addr == 0) && (mask == 0)) {
Any comments from gurus?
PS Sorry for a bit long message, i just want to make the things clear.
--
gonzo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh & select() problem on 5.3
On Sun, 2004-Nov-28 18:43:47 +0200, Claudiu Dragalia-Paraipan wrote: >Since the problem occurs only when I connect to the firewall or to a >server behind it, I started to suspect a hardware failure. Could a >network card cause such problems ? A couple of people have mentioned path-MTU problems. I've also bumped into this problem when playing with VLANs where one end of the VLAN trunk doesn't support long frames - an oversize packet will get ignored by the receiver without any error being returned. -- Peter Jeremy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HD Mirroring
On Wed, 2004-11-24 at 23:08, Justin Hopper wrote: > On Wed, 2004-11-24 at 13:31, Charles Sprickman wrote: > > On Wed, 24 Nov 2004, Brian Reichert wrote: > > > > > And, although I've not tested it, recent versions of MySQL can > > > outright support a cluster: > > > > > > http://dev.mysql.com/doc/mysql/en/NDBCluster.html > > > > I'm just curious if there's any other solution that will work on FreeBSD. > > I have about 5 mysql servers (4 slaves, 1 master) and one application in > > particular is not smart enough to try other servers if the configured > > server does not answer. Is there any type of local proxy that can > > intelligently route requests to the "best" server? > > > I too was curious about the MySQL Clustering support and its status on > FreeBSD, since it wasn't as a supported OS. Over the last couple of > hours I was able to set up a cluster consisting of a management process > and data node running in one jail, and a MySQL server and another data > node running in a different jail. Once everything was up and running, > the cluster seemed to be working excellent, data was synchronizing > flawlessly throughout the cluster. Nuking either of the data node > processes did not affect access to the data in the cluster, so failover > seemed to be working as well. > > The only problem that I ran into, and it may be user error on my part, > is that when the cluster is shut down (or all data node processes are > killed), the data contained in the node is lost when the cluster is > brought back online. Perhaps there is some recovery step that is > required before the cluster can be used again. > > If someone else has already tested MySQL's clustering ability with > FreeBSD, then please let us know the results so that I don't recreate > the wheel here. If not, I'll continue seeing how far I can get with it, > as I would definitely like to implement this functionality on several of > the more critical databases that I manage. I'm sure it's taboo to respond to one's own message, but thought I would follow up with some information on the problems I was running into with MySQL Cluster. The first problem, where it appeared that the data in the cluster was lost when the cluster was shut down, turned out to be there are some problems with the MySQL servers, which act as API clients to the cluster, reliably connecting into the cluster. Several times I could not get a MySQL server to connect to the cluster, but found no rhyme or reason for it so far. The cluster seems to be retaining data just fine upon shutdown, when the MySQL servers can actually connect to it to query data that is... The second problem I encountered was while trying to load a table that was 163MB in size that contained around 1 million rows. The NDB cluster would continually report that the table was "full" when trying to import the data. After checking around on mailing lists, I found out that the NDB clustering engine will require around table_size*2*10% RAM to load a table. NDB keeps all of the data in main memory, and has a fair amount of overhead per row. Perhaps somebody else can do a more thorough test of MySQL clustering on FreeBSD to make sure that it is in fact fully stable. It seems like a remarkable system, assuming you have the gigs of RAM it takes to run it with a table of any substantial size... -- Justin Hopper <[EMAIL PROTECTED]> UNIX Systems Engineer BSDHosting.net Hosting Division of Digital Oasys Inc. http://www.bsdhosting.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Integer divide panic in cambio
Is there a divide by zero possibility in cambio? Maybe mishandling of a zero sized disk? I still havn't gotten a crashdump yet as I have more than 4 Gig of memory in the machine, but the panic is an integer divide error with active process cambio. Background: I have a quad opteron server with one 2340 FC-AL Qlogic talking to a large EMC^2 array. On probe of the array, I get the above error. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hand on gmirror (Was: Re: gmirror bugs, how many?)
On Mon, Nov 29, 2004 at 12:52:40PM -0200, Jo?o Carlos Mendes Luís wrote: +> >+> Indeed, the -h option is what I wanted and the "bug" is in the +> >+> manual. What would happen if I change the disc ID in this case? +> > +> >Your disk will not be detected as a mirror component, because hardcoded +> >name is different. +> +> Oops. Is there a check for that? For example, let's say that ad0s1 got +> renamed to ad1s1, and hardcoded a reference to ad0s1. In this case, +> there is a disk called ad0s1 in the system. Is gmirror smart enough in +> this case? In this case ad1s1 will not be connected to the mirror (but don't worry, ad0s1 will not be connected as well). +> >+> sigesc::root jcmendes [553] disklabel mirror/vol0 +> >+> # /dev/mirror/vol0: +> >+> 8 partitions: +> >+> #size offsetfstype [fsize bsize bps/cpg] +> >+> a: 16498864 16unused0 0 +> >+> c: 164988800unused0 0 # "raw" part, +> >+> don't edit +> >+> sigesc::root jcmendes [554] +> >+> +> >+> Seems good until now. Except for the offset 16 of the "a" partition. +> >+> Is this necessary? The man page says that the only sector reserved +> >+> for metadata is the provider's last one. +> > +> >Ehh, "blame" disklabel(8). First 16 sectors are reserved for boot code. +> +> And why this does not happen with ad0s1, etc? I think it should, only using sysinstall for this will not allocate those sectors. Anyway, it has nothing to do with gmirror. -- Pawel Jakub Dawidek http://www.FreeBSD.org [EMAIL PROTECTED] http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! pgpcMmdf82g2J.pgp Description: PGP signature
Re: USB developer please look at cdce driver -- (Was: Driver for Yopy PDA)
> On Tue, Nov 23, 2004 at 11:09:59AM +0100, Marco van de Voort wrote: > > I'm also in need for a cdce device. > > > > I had the below URL running with 5.2 (and some currents from mid-summer), > > but it fails to compile with 5.3 > > > > http://www.gank.org/freebsd/cdce.tar.gz > > When did you pull down that tarball? I updated the driver at that > location a few days ago to make it compile on 5.3 (though I haven't > tested it with a real device yet). > > Thanks to Dave Smith for pointing out to me last week that it wasn't > working. I tested it in RC1 times. Thanks for fixing! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hand on gmirror (Was: Re: gmirror bugs, how many?)
Pawel Jakub Dawidek wrote: Not working 'unload' command is because of bug in GEOM. Now, to avoid deadlock you get an error (ENXIO), but mirror will be destroyed. The next 'unload' should be ok. To avoid those errors, you should first stop all mirrors (unsing 'stop' command) and then unload kernel module. I thought unload did a stop before. BTW. There is no 'reload' command. I know, I meant redoing the load command. +> Indeed, the -h option is what I wanted and the "bug" is in the +> manual. What would happen if I change the disc ID in this case? Your disk will not be detected as a mirror component, because hardcoded name is different. Oops. Is there a check for that? For example, let's say that ad0s1 got renamed to ad1s1, and hardcoded a reference to ad0s1. In this case, there is a disk called ad0s1 in the system. Is gmirror smart enough in this case? +> sigesc::root jcmendes [553] disklabel mirror/vol0 +> # /dev/mirror/vol0: +> 8 partitions: +> #size offsetfstype [fsize bsize bps/cpg] +> a: 16498864 16unused0 0 +> c: 164988800unused0 0 # "raw" part, +> don't edit +> sigesc::root jcmendes [554] +> +> Seems good until now. Except for the offset 16 of the "a" partition. +> Is this necessary? The man page says that the only sector reserved +> for metadata is the provider's last one. Ehh, "blame" disklabel(8). First 16 sectors are reserved for boot code. And why this does not happen with ad0s1, etc? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsdtar needs --ignore-zero & --ignore-failed-read
This follows on from my post to [EMAIL PROTECTED]: Date: 16th Nov 2004 21:35 Subject: Re: 5.3-RC2 tar breaks operation with "(null)" I've upgraded to 5.3-RC2 in November and have noticed that bsdtar is now the standard Tape Archiver. While I do appreciate the simplicity of the new interface, it does lack a couple of essential options; in particular, those dealing with failed media. I found this out when attempting to extract an archive from a CD-RW. It had a few bad blocks so the drive just returned blocks of zero where these occured. This was enough to stop the extract operation dead in its tracks. I copied this to disc with dd and ran the extract operation again but it could not read past the corrupt portion. I was able to work around it with gtar and the --ignore-zero and --ignore-failed-read options but I could not find an equivalent solution for bsdtar. My suggestion is to include these options in libarchive and to assert --ignore-zero in bsdtar by default on plain files (i.e. those not on sequential media, not on a character special device file but on a random access file system). In the case of a plain file extracted with tar, the complete contents should be read. I'm not aware of any case where people typically append anything other than TAR dumps to an archive. For other programs (pkg_add), it may be best to leave this turned off. Regards, Andrew Sinclair. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ssh & select() problem on 5.3
On Sun, Nov 28, 2004 at 06:43:47PM +0200, Claudiu Dragalia-Paraipan wrote: > > Since the problem occurs only when I connect to the firewall or to a > server behind it, I started to suspect a hardware failure. Could a > network card cause such problems ? > The firewall is running on FreeBSD 5.2.1 with PF+ALTQ, and I can observe > the same behaviour: dmesg locks ssh connection. I have test this with PF > disabled, and the problem still occurs, so I can eliminate PF as a problem. Perhaps an MTU problem, with the ICMP "fragmentation needed but DF set" being blocked by the firewall? It would only show up when the server has enough to send to fill a packet. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
transfer control to usb driver
Hello, I am using Freebsd 5.2. I wrote a driver whose ATTACH()/DETACH() routines are called correctly when the usb device is attached/detached. But when I do an open()/read()/ioctl()/close() -it calls usbopen(), usbread(), usbioctl() etc.. instead of calling mydriverread(), mydriverioctl()... I have copied src from urio.c into my skeletal driver -and it should have worked (assuming the former does). What could be the error? thanks -kamal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A hack to rebuild port KLDs during kernel builds
On Mon, Nov 29, 2004 at 10:54:26PM +1030, Daniel O'Connor wrote: > Hi, > I have a few "third party" KLDs on my system (nvidia, acpi_ppc, dell, > if_ndis) > and it's quite annoying to have to rebuild them each kernel build, or > upgrade. I have thought about putting them in /boot/modules but I have had > this crash on my fairly often (esp since I am running -current). > > If you want to try it.. > Apply the diff and make /usr/local/kld and copy port-makefile.txt there as > Makefile. > > Note that (obviously) the ports need to be tweaked to install the driver > source and build infrastructure there, but that's not too hard (to do by hand > for now anyway). I have the 4 I mentioned building just fine with 5 minutes > work. > Any chance you can use the recently added PORTS_MODULES knob to do what you want? : # cvs -R log -N -r1.71 kern.post.mk : : RCS file: /home/ncvs/src/sys/conf/kern.post.mk,v : Working file: kern.post.mk : head: 1.73 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 74;selected revisions: 1 : description: : : revision 1.71 : date: 2004/11/11 23:58:14; author: imp; state: Exp; lines: +14 -0 : PORTS_MODULES: a list of ports to build with this kernel. : : # I directly use the targets for building this, but it was suggested : # to use portupgrade. I couldn't fit that into the target model, so I : # punted. : = Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpIz0SLAWTYY.pgp Description: PGP signature
A hack to rebuild port KLDs during kernel builds
Hi,
I have a few "third party" KLDs on my system (nvidia, acpi_ppc, dell, if_ndis)
and it's quite annoying to have to rebuild them each kernel build, or
upgrade. I have thought about putting them in /boot/modules but I have had
this crash on my fairly often (esp since I am running -current).
If you want to try it..
Apply the diff and make /usr/local/kld and copy port-makefile.txt there as
Makefile.
Note that (obviously) the ports need to be tweaked to install the driver
source and build infrastructure there, but that's not too hard (to do by hand
for now anyway). I have the 4 I mentioned building just fine with 5 minutes
work.
--
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
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
# I live in /usr/local/kld/Makefile
SUBDIR!=/usr/bin/find . -maxdepth 1 -type d \! -name . \! -name CVS |
/usr/bin/xargs /bin/echo
.include
Index: sys/modules/Makefile
===
RCS file: /usr/CVS-Repository/src/sys/modules/Makefile,v
retrieving revision 1.410
diff -u -p -r1.410 Makefile
--- sys/modules/Makefile 16 Nov 2004 17:19:04 - 1.410
+++ sys/modules/Makefile 29 Nov 2004 12:21:58 -
@@ -166,6 +166,7 @@ SUBDIR= ${_3dfx} \
plip \
${_pmc} \
portalfs \
+ ${_ports} \
ppbus \
ppi \
pps \
@@ -260,6 +261,11 @@ _syscons= syscons
_ufs= ufs
.endif
+PORTSKLD?= /usr/local/kld
+.if exists(${PORTSKLD}) && !defined(NO_PORTS_KLDS)
+_ports= ../../../../${PORTSKLD}
+.endif
+
.if !defined(NOCRYPT) || defined(ALL_MODULES)
.if exists(${.CURDIR}/../opencrypto)
_crypto= crypto
pgpqXe4hMFqBV.pgp
Description: PGP signature
