blog'o thnet

To content | To menu | To search

Tuesday 1 November 2005

Maintainer of The www/nanoblogger FreeBSD's Port

Just to say that i am the new maintainer of the www/nanoblogger port for the FreeBSD project (for some weeks now). See Problem Report ports/84817 for complete patch and update history.

Here is an excerpt of the PR description:

  • Make portlint(1) happy (portlint -A)
  • Add the files pkg-plist and pkg-message
  • The port conforms a little more to the Porter's Handbook
  • Validate a complete recommended test ordering from porting-testing.html

As a side note, the additional contributors list was not updated to reflect the change of maintainer ship... Not so very important, i think ;-)

Friday 28 October 2005

FreeBSD LORs (Lock Order Reversal)

I encountered two LORs in the past, especially during the testing phase of the just behind the corner FreeBSD 6.0 release.

I already reported about two of them, but wanted to point out that the second seems to be fixed, as shown in this patch. Regrettably, the MFC seem not to have taken place in the RELENG_6 branch... yet. On the other side, this one is not known to generate panic or some other bad behavior, so i think it is ok.

Wednesday 26 October 2005

Chasing FIFO Bug

When testing RELENG_6 (for weeks now), i encountered a strange bug running an UP and a SMP kernel under heavy parallel load, as when building the world using the -j flag. The symptom was simply a panic, no more no less.

After posting about it on current@, i received good help from Robert N M Watson himself asking for crash dump and testing. After some work on his side, he came with a lot of work on the FreeBSD's FIFO implementation, now committed to the source tree.

As a side note, it be mentioned that these modifications seems to solve the problem even on the UP machine, but Robert said that this one may had another origin and may not be totally solved. Here is an excerpt of one of his reply:

This is actually interesting -- Kris Kenneway reported the same thing -- that is, that with the most recent spate of FIFO bug fixes, the problem has gone away. The only problem is that I don't think I fixed a bug with the symptoms that you have experienced, which suggests instead that I've changed the timing of the bug so that it occurs less rarely. I sent Kris a set of assertion patches to run with, and he generates some nice parallel make load, and I have a regression test I've been running. I think we're set for now and I'll continue to work on reproducing it after my recent fifo cleanup. It is possible I fixed a race condition without meaning to, of course... Please let me know if you have any further FIFO panics! Thanks again, Robert N M Watson

I just can say that panic doesn't occur since then. Thanks to him.

Sunday 23 October 2005

FreeBSD's Upcoming 6.0 Release

After playing with RELENG_6 for a while, i can now safely says that the new upcoming FreeBSD release will be a very good release(TM)! Altogether, the operating system is very stable and have a good responsiveness.

But... my main problem encountered with my laptop still remain: a long standing problem with the GigE Ethernet driver re(4). See Problem Report kern/80005 for more information on that subject. Just note that the problem was not solved (nor changed) trying the new polling(4) operational mode, nor trying the development branch of FreeBSD: 7-CURRENT, as somebody had advised it to me in the past... Too bad.

Thursday 18 August 2005

Update the Notebook to FreeBSD 6.0-BETA2

I decided to take advantage of this three days week-end (at least in France) to upgrade the Notebook to FreeBSD 6.0-BETA2 and follow the RELENG_6 branch testing the upcoming FreeBSD release.

In fact, i hope this one may help me in two areas... more precisely: fix a very annoying bug resulting in a USB interrupt storm and help on the wifi side, based on the work done to incorporate the wpa_supplicant code from ports(7).

The installation went smooth and well, although there is no package yet (it is a beta release, not a release candidate) and all third party need to be compile from sources. So, i installed the minimum required. In the same time, update (one more time) the installation notes, notably regarding the DHCP part (this branch switched from the ISC DHCP client v3.x to the OpenBSD DHCP client which was based on ISC DHCP v2.x). The biggest problem was to figure how to set it up in order to be able to update its DNS records obtained from the DHCP server. The solution is very simple: don't let the client do this setting (as in RELENG_5 with ISC DHCP) but do it on the server side level. It has the other advantage not to care how to do this on multiple heterogeneous clients (UNIX, Unix-like, Windows, etc.).

On the other side, there is one problem though. Because this release needs testing, the default kernel comes with debugging options enable (INVARIANTS and WITNESS(4) in particular) which have the side effect of slowing down the machine, really. These options help debugging and lightning some problems that may appeared in the development process. One of this is called a LOR and i encountered two of them. They are already known to the developers, but we don't know yet the real impact of these: harmless or not. Here is the thread about this on current@.

Go testing. I will try to reproduce the panic i encountered before to know the code path where this happens.

Thursday 21 July 2005

Broken RAID Array... Found the First Guilty Component

Last week, the mirror array for the system broke one more time. After some investigation, It turns out to be a faulty Serillel adapter. Luckily i had one more of this in the stock... just in case (what a good idea, isn't it?).

On the other hand, the mirror array for the data (home directories) broke itself during the overall restore procedure. Still in this degraded mode for now, need more time to work on this... quickly :(

# grep DEGRADED /var/log/messages | tail -1
Jul 17 17:54:24 bento kernel: ar1: 117246MB <ATA RAID1 array> [14946/255/63] status: DEGRADED subdisks:

# atacontrol status ar1
ar1: ATA RAID1 subdisks: ad8 status: DEGRADED

Don't forget to make some good backups! There is no good reason not to do so. It is just a matter of time to use them.

Tuesday 19 July 2005

Updating the FreeBSD's Port of NanoBlogger to Release 3.2.3

After deciding to use the NanoBlogger tool to maintain my little space on the web, i had updated the corresponding ports(7) on FreeBSD, currently orphaned at the time of this writing.

The all in one patch produced was committed by Pav Lucistnik, many thanks to him.

As a side note, it may be pointed out that this port include a local FreeBSD port's patch in order to bypass a little bug when creating a new weblog in release greater than 3.2.1 (and so present in 3.2.3). See bug report 1232755 for more information about this issue.

Friday 8 July 2005

Rebuilding ATA RAID-1 Array Using FreeBSD 5.X

Ouch! This morning i discovered that one of the mirror for the system array disks was broken on one of the servers, as can be show in the /var/log/messages log file:

Jul  1 08:22:56 bento kernel: ad4: FAILURE - WRITE_DMA status=51<READY,DSC,ERROR> error=14<NID_NOT_FOUND,ABORTED> LBA=16082271
Jul  1 08:22:56 bento kernel: ar0: WARNING - mirror lost
Jul  1 08:22:57 bento kernel: ad4: FAILURE - WRITE_DMA status=51<READY,DSC,ERROR> error=14<NID_NOT_FOUND,ABORTED> LBA=16099295

So, assuming that the hardware error is not so bad and maybe recoverable (i really don't want to replay the last backups if i can), i follow these steps to rebuild the faulting RAID1 array...

Check for more information on ATA devices and the impacted array:

# atacontrol list
ATA channel 0:
    Master: acd0 <SAMSUNG CD-ROM SC-152L/C100> ATA/ATAPI revision 0
    Slave:       no device present
ATA channel 1:
    Master:      no device present
    Slave:       no device present
ATA channel 2:
    Master:  ad4 <Maxtor 6Y080P0/YAR41VW0> ATA/ATAPI revision 7
    Slave:       no device present
ATA channel 3:
    Master:  ad6 <Maxtor 6Y080P0/YAR41VW0> ATA/ATAPI revision 7
    Slave:       no device present
ATA channel 4:
    Master:  ad8 <Maxtor 6Y120P0/YAR41VW0> ATA/ATAPI revision 7
    Slave:       no device present
ATA channel 5:
    Master: ad10 <Maxtor 6Y120P0/YAR41VW0> ATA/ATAPI revision 7
    Slave:       no device present
#
# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad6 status: DEGRADED

Detach the disk from the array (then it will be safely removable if necessary):

# atacontrol detach 2
#
# grep ad4 /var/log/messages | tail -1
Jul  2 11:13:40 bento kernel: ad4: WARNING - removed from configuration

Reattach the disk to the configuration:

# atacontrol attach 2
Master:  ad4 <Maxtor 6Y080P0/YAR41VW0> ATA/ATAPI revision 7
Slave:       no device present
#
# grep ad4 /var/log/messages | tail -1
Jul  2 11:13:47 bento kernel: ad4: 78167MB <Maxtor 6Y080P0/YAR41VW0> [158816/16/63] at ata2-master UDMA133

Add a spare disk (the same as before in fact, in our case) to the existing system RAID:

# atacontrol addspare ar0 ad4
#
# grep ad4 /var/log/messages | tail -1
Jul  2 11:14:03 bento kernel: ad4: inserted into ar0 disk0 as spare

Rebuild the RAID1 dynamically:

# atacontrol rebuild ar0

Check the progression of the rebuild:

# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 7% completed

When all is done, this can be shown using atacontrol(8) as follow:

# atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: READY

page 2 of 2 -