13 August, 2006
Of New Hardware, New Packages, Bugs & Kernels
I decided that before my socket 939 ASUS A8V Deluxe motherboard becomes obsolete, I should do an upgrade to dual-core. It so happened that my dealer had an Athlon64 X2 4800+ returned to him the other week, so I went for it. It's the fastest that the board supports and comes with juicy 2x 1MB L2 cache (which apparently got axed by AMD now as part of the price-battle with Intel). My only concern was about power/heat/noise because it's the 110W model, but to my delight it appears to be running cooler and quieter than the (130nm) 3500+ I had before. Cool! ;-) While I was at it I also doubled the RAM to 2GB and bought two SATA hard disks and a swappable tray system for them.
The latter was mainly so I could do some tests in regards to #380703. The outcome is that restore works fine with SATA disks on above motherboard using its Via SATA controller (haven't tried the Promise one yet). So far, so good - or rather bad, because I can't produce the problem.
At least I do have a fix for #379966 which basically entices the introduction of a new function mr_stresc() to properly escape things when using system() or popen(). It's gone through a few revisions both by the submitter and upstream (Thanks Steve & Bruno!) and should be in upstream soon.
For the time being, I have just uploaded mindi-1.09-1 and mondo-2.09-1. They are purely new upstream versions and don't close any of the open bugs - hopefully, this will follow soon. Testing was done on an etch system using a SATA disk and a sid system using PATA. The archiving mode was NFS both times and the kernel used was also the same, i.e. 2.6.16-2-amd64-k8-smp (2.6.16-17).
I am experiencing problems with 2.6.17 kernels and creating ISO images on NFS mounts using mkisofs. mksiofs would just hang sooner or later whilst writing the image file. With 2.6.16 there is no such issue. And neither cp nor dd have this problem with 2.6.17. Weird. I'll have to do some more testing and probably will bring it up on the debian-kernel list before I file a bug report.
The latter was mainly so I could do some tests in regards to #380703. The outcome is that restore works fine with SATA disks on above motherboard using its Via SATA controller (haven't tried the Promise one yet). So far, so good - or rather bad, because I can't produce the problem.
At least I do have a fix for #379966 which basically entices the introduction of a new function mr_stresc() to properly escape things when using system() or popen(). It's gone through a few revisions both by the submitter and upstream (Thanks Steve & Bruno!) and should be in upstream soon.
For the time being, I have just uploaded mindi-1.09-1 and mondo-2.09-1. They are purely new upstream versions and don't close any of the open bugs - hopefully, this will follow soon. Testing was done on an etch system using a SATA disk and a sid system using PATA. The archiving mode was NFS both times and the kernel used was also the same, i.e. 2.6.16-2-amd64-k8-smp (2.6.16-17).
I am experiencing problems with 2.6.17 kernels and creating ISO images on NFS mounts using mkisofs. mksiofs would just hang sooner or later whilst writing the image file. With 2.6.16 there is no such issue. And neither cp nor dd have this problem with 2.6.17. Weird. I'll have to do some more testing and probably will bring it up on the debian-kernel list before I file a bug report.
# posted by Andree Leidenfrost @ 8:47 pm 
