Re: HP LJ 1020: ulpt0: offline

[Bruce Simpson]

Graham Menhennitt wrote:

Foo2zjs doesn't seem to have changed recently. CUPS has changed but I
doubt that's the problem. Maybe something to do with USB drivers?
  


In 8.x, CUPS 1.4.x wants libusb support and the ugen driver, rather than 
ulpt. Once I changed over to that, all was fine.


It's a mite irritating that device permissions can't be tied down easily 
as they can with ulpt(4), because CUPS needs to see the /dev/usb/* 
device nodes. On my print server, I just have devfs rules for the new 
device nodes.


P.S. uscanner has also gone away. I use a multi-function device (Epson 
CX3650). The sane-backends can also use libusb now.


cheers,
BMS
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Stability problems with 7-stable (after 7.1 - 7.2 - 7-stable)

[Alexander Leidinger]

Hi,

please CC me on replies.

I have a system which was at 7.1-pX. After the update to 7.2-p5 it  
started to exhibit deadlocks after some minutes of uptime.


With 7.1 (generic kernel) it was running fine, with 7.2 generic the  
problems started directly.


The system is now at 7-stable with a custom kernel  
(http://www.Leidinger.net/test/ALCATRAZ), basically generic without  
unneeded drivers plus witness/invariants/sw-watchdog.


The system is an AMD Dual Core with NVidia MCP61 chipset  
(http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2 harddisks  
and FreeBSD 32bit install.


On the system are 3 jails (one postfix+mysql+apache, one  
mysql+apache+some-perl-service, one apache+mysql+xmpp-server). All of  
them have a 7-stable world.


The 2 disks where configured with 3 partition pairs for root-mirror,  
swap-mirror, and jail-mirror.


I tested with and without SMP, both schedulers, with  
WITNESS/INVARIANTS, and by removing one part of each mirror (to rule  
out that the disks are not in sync). In all cases the system was not  
stable and deadlocked after several minutes (even with only the  
mail-jail up and running). First no interaction via ssh is possible  
anymore, then even ping does not work anymore. After configuring the  
watchdog, I got at least the system back online automatically... :(


After reading  
http://www.mail-archive.com/freebsd-stable@freebsd.org/msg96901.html I  
decided to switch the FS for the jails to ZFS (currently only on one  
harddisk, the other partition for it is still with UFS, but not  
mounted at all) as a test.


Now with a little bit of kernel tuning for ZFS  
(http://www.Leidinger.net/test/loader.conf.alcatraz) I was able to  
keep the system up for about 3h with all jails activated (I started  
one jail after another, with waiting 1h between starting each jail).  
After that no access via ssh, no ping, but also no reboot from the  
sw-watchdog, I had to do a remote power-off/-on. After that I didn't  
had any crashdump (in the watchdog cases I had dumps, but since I  
recompiled the kernel since then, I can not provide useful output).


The current gmirror status output is at
   http://www.Leidinger.net/test/gmirror.alcatraz

The system has no serial console. I have no physical access.

For such a small setup I would expect that 7.2-GENERIC is more than  
enough. At least 7.1-GENERIC was running without any problem.


Does this problem sound familiar to someone, any ideas what to try,  
anyone with patches I could test?


Bye,
Alexander.

--
I'm not a real movie star -- I've still got the same wife I started out
with twenty-eight years ago.
-- Will Rogers

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Karl Denninger]

Juergen Lock wrote:
 Hi!

 In article 4b150d60.5050...@denninger.net you write:
   
 -=-=-=-=-=-

 Jeremy Chadwick wrote:
 
 On Sat, Nov 28, 2009 at 09:43:25PM -0600, Karl Denninger wrote:
   
   
 Karl Denninger wrote:
 
 
 Jeremy Chadwick wrote:
   
   
   
 On Fri, Nov 27, 2009 at 12:54:17PM -0600, Karl Denninger wrote:
   
 
 
 
 For what its worth, USB-based serial adapters also fail in the same way,
 but faster (they have NEVER been reliable in this regard, and this
 hasn't improved)
 
   
   
   
 There must be a regression of some kind, given that some FreeBSD
 developers have stated in the past that FTDI-based USB serial adapters
 work great:

 http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041615.html

 Original thread:

 http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041610.html
   
 
 
 
 I don't know where works great has come from.  Certainly not my
 experience in heavy use.

 For non-modem-control heavy use, it works ok.  I use an 8-port fanout on
 7.x to drive process control and it's stable.

 However, for heavy modem use (e.g. Hylafax) it has NEVER been stable -
 although in 8.x it won't even manage to send ONE 10-page fax most of the
 time, where under 7.x it would randomly fail in that use.  Then again
 the puc() driver based serial I/O was completely stable under 7.x and
 now, with the new architecture it will get one or two jobs through it
 before it blows up.

 -- Karl
   
   
   
 FYI I downgraded back to 7.2-STABLE (it was a bit hairy but I got it to
 work after a small amount of screwing around) via sources
 and again the machine and those serial ports are 100% stable with the
 old driver infrastructure.

 The uart() infrastructure in 8.x has to be considered broken and
 unusable for modems at this point folks.  I recognize that nobody
 flagged it until just before the release (I hadn't tried it until RC2,
 and thus didn't know) but this is a literal dagger in the heart of
 anyone who needs to put an actual modem on an 8.x box using the common
 cards out there, and I assume it will bite just as hard for things like
 a dial-in console as it will for a fax server.
 
 
 Karl,

 I agree with you in this regard.  However, I'm not sure what to
 recommend to you with regards to getting this issue the proper attention
 it needs.  I fully agree with the Severity (serious) and Priority
 (high) of the PR:

 http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/140947

 Ed Schouten appears to be giving this attention, but I'd recommend that
 Email communication include mar...@freebsd.org, just in case it turns
 out that puc(4) needs some changes.  I'm certain Ed will do his best to
 assist tracking this one down.  :-)
   
   
 Added the suggested forward address to the list. just in case :)

 Yeah, this is pretty serious.  It looks to me, at first blush, like an
 interrupt is being dropped on occasion and there is no watchdog timer in
 the driver code to catch it and unwedge the state machine.  That's not
 supposed to be possible (dropped interrupts) on PCI (and PCI/Express)
 cards unless something is dramatically wrong in the code somewhere.
 

  It just occured to me that this might be related to a bug I fixed
 in qemu's serial hw emulation,
   
 http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=2d6ee8e7e17227d5eb8c6e9a054dd88d5b37c5ae
 which also caused tx irqs to get lost and which the old sio(4) driver had
 no problem with, only output on uart(4) then hung as a result.  On that
 occasion I also learned that there is a priority list for irqs, for example
 rx irqs take precedence over tx ones, so maybe that explains why some irqs
 can get lost during `heavy use'?  (And which the old driver recovered from
 I guess by checking status registers at least in the tx path too in
 addition to just accounting for irqs.)

  HTH,
   Juergen
   
This is now marked fixed and it appears (after limited testing thus far)
that it indeed is.

Thank you.

-- Karl

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Stability problems with 7-stable (after 7.1 - 7.2 - 7-stable)

[Ivan Voras]

Alexander Leidinger wrote:

Hi,

please CC me on replies.

I have a system which was at 7.1-pX. After the update to 7.2-p5 it 
started to exhibit deadlocks after some minutes of uptime.


With 7.1 (generic kernel) it was running fine, with 7.2 generic the 
problems started directly.


The system is now at 7-stable with a custom kernel 
(http://www.Leidinger.net/test/ALCATRAZ), basically generic without 
unneeded drivers plus witness/invariants/sw-watchdog.


The system is an AMD Dual Core with NVidia MCP61 chipset 
(http://www.Leidinger.net/test/dmesg.alcatraz), 2 GB RAM, 2 harddisks 
and FreeBSD 32bit install.


Some generic things to try:
	- did you monitor the system with something (top or systat -vm) to see 
if there is something unusual, like interrupt storms?
	- no physical access is a problem; If you do manage it, I'd say try 
running single user for some time with systat -vm just to see what happens.


I would not trust ZFS in 7-stable since it lags a bit behind patches 
done to 8 but 7.2 should be fine - at least I don't have any such 
problems with it (though no AMD boxes to test them with it).


If you haven't updated your ZFS pools, I'd suggest reverting back to 
7.1, then building or downloading an 8.0 kernel and try it with 7.1 
userland (reboot -k ...) simply to see if it helps.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Dell D830, nVidia and FreeBSD-8/amd64

[John Baldwin]

On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote:
 On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote:
  On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote:
   Hi,
   
   This is a general rehash of a problem that I've been having with my
   Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics
   card. I've been using the XOrg's vesa driver ever since something in 
the
   code rendered the nvidia driver inoperable in 7-STABLE sometime mid
   last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I
   could bypass the problem. Unfortunately, I seem to be experiencing the 
same
   problem as described in the following thread:
   
  http://www.nvnews.net/vbulletin/showthread.php?t=142391
   
   which appears to be implying that something in the kernel is
   interfering with memory allocation. Would it be possible for someone
   with deeper kernel-fu be able to take a look at this issue?
  
  Do you have a verbose dmesg available?
 
 I've attached a dmesg with a verbose boot. I hope this is what you're
 looking for.

Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'?  I suspect that 
when the bridge allocates the prefetch resource range from the parent it is 
failing somehow.  For a quick hack try something like this:

Index: subr_rman.c
===
--- subr_rman.c (revision 200359)
+++ subr_rman.c (working copy)
@@ -284,7 +284,7 @@
   count, flags,
   dev == NULL ? null : device_get_nameunit(dev)));
want_activate = (flags  RF_ACTIVE);
-   flags = ~RF_ACTIVE;
+   flags = ~(RF_ACTIVE | RF_PREFETCHABLE);
 
mtx_lock(rm-rm_mtx);
 


-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 8 GPT install, how?

[Torfinn Ingolfsen]

On Thu, 03 Dec 2009 03:03:29 -0600
Scot Hetzel swhet...@gmail.com wrote:

 If you have a look at the Root On ZFS tutorial, it shows how to create
 a GPT formated system from the Fixit environment:
 
 http://wiki.freebsd.org/RootOnZFS

Just FYI, this tutorial worked nicely with the memtick image,
installing on a amd64 machine.
-- 
Regards,
Torfinn Ingolfsen

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: FreeBSD 8 GPT install, how?

[Torfinn Ingolfsen]

On Tue, 15 Dec 2009 17:54:06 +0100
Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote:

 On Thu, 03 Dec 2009 03:03:29 -0600
 Scot Hetzel swhet...@gmail.com wrote:
 
  If you have a look at the Root On ZFS tutorial, it shows how to
  create a GPT formated system from the Fixit environment:
  
  http://wiki.freebsd.org/RootOnZFS
 
 Just FYI, this tutorial worked nicely with the memtick image,

s/memtick/memstick/

sigh.
-- 
Regards,
Torfinn Ingolfsen

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

problems with SATA controller after recent RELENG_8 upgrade

[Oliver Lehmann]

Hi,

I've just upgraded my 8 from around the 6th of december 2 days ago. Now
the system won't boot up. When it is going to mount the rootfs, it
receives some ICRC error and the harddisk gets accessed massivly. The the
error shown on the screenshot is repeating and repeating. Apart from my
custom kernel I also compiled and tried the GENERIC kernel with some
additional modules (ipfw, dummynet, smb, intpm, pcfclock - nothing which
should interfear)
The filesystem is labeled with glabel/tunefs.

Could you advise me what to do next? Right now I'm using the old kernel...

Screenshot (where I tried to reach at least single user):

   http://pics.pofo.de/gallery/v/misc/P1090111.JPG.html


The controller and harddisk in question:

atapci1: Promise PDC40775 SATA300 controller port 0xec00-0xec7f,0xe800-0xe8ff 
mem 0xffaff000-0xffaf,0xffac-0xffad irq 11 at device 17.0 on pci0
atapci1: [ITHREAD]
atapci1: [ITHREAD]
ata2: ATA channel 0 on atapci1
ata2: SIGNATURE: 0101
ata2: [ITHREAD]
ata3: ATA channel 1 on atapci1
ata3: [ITHREAD]
ata4: ATA channel 2 on atapci1
ata4: [ITHREAD]

ad4: 238475MB WDC WD2500KS-00MJB0 02.01C03 at ata2-master SATA300
GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s).
Trying to mount root from ufs:/dev/ufs/root


-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Marcel Moolenaar]

On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote:

 This is now marked fixed and it appears (after limited testing thus far)
 that it indeed is.

The bug existed in 7 as well. It's not a regression introduced in 8.
The reason why this didn't come up in the 7 time frame is that sio(4)
was still the default. Jeremy has been an early adopter of uart(4)
and if I'm not mistaken, he always loaded the driver(s) as modules.
This, due to a lucky bug, avoided the problem for him.

In depth:

With uart(4) I created the serdev I/F. This is an interface that
allows umbrella drivers like puc(4) and scc(4) to obtain pending
interrupt status and invoke interrupt source specific handlers.
This puts the umbrella driver in control over what gets handled
in what order *across* multiple interfaces. As such, with puc(4),
you can service all receive interrupts for all ports before you
service, say, the transmit interrupt across the ports.

When a serial device does not implement the serdev I/F, then
puc(4) won't be involved in interrupt handling at all. This is
why puc(4)+sio(4) had no problem. Since uart(4) does implement
the serdev I/F, the interrupt handler of puc(4) would be in
control and since it was this interrupt handler that was broken,
exhibit the stalls.
But, when puc(4) and/or uart(4) were loaded as modules, puc(4)
would not see uart(4) as implementing the serdev I/F. This is
to do with linker sets, etc. Consequently, uart(4) would handle
its own interrupts and puc(4) would not be involved (just as
with the sio(4) setup). In that scenario puc(4)+uart(4) also
just worked.

In any case: puc(4) has been fixed and I'll deal with the linker
set bug later. For best results: compile puc(4) and uart(4) into
the kernel and don't load them as modules for now...

FYI,

-- 
Marcel Moolenaar
xcl...@mac.com



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Karl Denninger]

Marcel Moolenaar wrote:
 On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote:

   
 This is now marked fixed and it appears (after limited testing thus far)
 that it indeed is.
 

 The bug existed in 7 as well. It's not a regression introduced in 8.
 The reason why this didn't come up in the 7 time frame is that sio(4)
 was still the default. Jeremy has been an early adopter of uart(4)
 and if I'm not mistaken, he always loaded the driver(s) as modules.
 This, due to a lucky bug, avoided the problem for him.

 In depth:

 With uart(4) I created the serdev I/F. This is an interface that
 allows umbrella drivers like puc(4) and scc(4) to obtain pending
 interrupt status and invoke interrupt source specific handlers.
 This puts the umbrella driver in control over what gets handled
 in what order *across* multiple interfaces. As such, with puc(4),
 you can service all receive interrupts for all ports before you
 service, say, the transmit interrupt across the ports.

 When a serial device does not implement the serdev I/F, then
 puc(4) won't be involved in interrupt handling at all. This is
 why puc(4)+sio(4) had no problem. Since uart(4) does implement
 the serdev I/F, the interrupt handler of puc(4) would be in
 control and since it was this interrupt handler that was broken,
 exhibit the stalls.
 But, when puc(4) and/or uart(4) were loaded as modules, puc(4)
 would not see uart(4) as implementing the serdev I/F. This is
 to do with linker sets, etc. Consequently, uart(4) would handle
 its own interrupts and puc(4) would not be involved (just as
 with the sio(4) setup). In that scenario puc(4)+uart(4) also
 just worked.

 In any case: puc(4) has been fixed and I'll deal with the linker
 set bug later. For best results: compile puc(4) and uart(4) into
 the kernel and don't load them as modules for now...

 FYI,
   
uart(4) is defined in the GENERIC file; I am compiling in puc(4) at
present in my kernel.

-- Karl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Jeremy Chadwick]

On Tue, Dec 15, 2009 at 09:57:59AM -0800, Marcel Moolenaar wrote:
 
 On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote:
 
  This is now marked fixed and it appears (after limited testing thus far)
  that it indeed is.
 
 The bug existed in 7 as well. It's not a regression introduced in 8.
 The reason why this didn't come up in the 7 time frame is that sio(4)
 was still the default. Jeremy has been an early adopter of uart(4)
 and if I'm not mistaken, he always loaded the driver(s) as modules.
 This, due to a lucky bug, avoided the problem for him.

Marcel,

Thanks for fixing the problem Karl's reported.  As I've stated in the
past, I appreciate your efforts and attentiveness to this sort of thing.
If there's any way I can repay you (Paypal donations, etc.), just let me
know and I'll do what I can.

With regards to my early testing of uart(4): I still use sio(4) on our
RELENG_7 systems, as I wasn't entirely sure if uart(4) was stable enough
or not (we use uart(4) reliably on our RELENG_8 systems though).  During
my brief testing of uart(4), it was most definitely compiled in to the
kernel(**).

Chances are I didn't uart(4) long enough (rather: use the serial port
enough!) to really give things a good whack.  Given that Karl's using
them for modems, I'd say his chance of seeing interrupt-related issues
are a lot higher than mine.

The serial ports on our systems are used solely for serial console
(115200bps, 8N1, CTS/RTS flow control), and with uart(4) worked OK for
the single-user-based steps of reinstalling world/mergemaster/etc..

I don't think puc(4) was in use, but I'm not 100% certain (I remember
including the device line in the kernel config, but I didn't see any
mention of anything attached to puc in dmesg; they all showed up as
being attached to acpi0).

(**): I tend to avoid kernel modules due to habit -- I guess because I'm
not sure if the module infrastructure is 100% reliable or not; scarce
are the number of times I've heard of someone encountering problems with
them, but old habits die hard...

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Trouble with drive size detection - 31MB visible size on 1TB drive.

[KOT MATPOCKuH]

2009/12/12 Alexander Motin m...@freebsd.org:
 To unlock drive permanently SET MAX ADDRESS ATA command should be used
 (probably the same as Linux uses) with Volatile bit set, to make it not
 restore on power cycle. I don't know how to send this command with
 legacy ata(4), you need some external tool.
Who knows this some external tool? :)
As I know hdparm is not ported to *BSD.

 With new CAM-based ATA
 probably it can be send via `camcontrol cmd ...`.
On this machine I'm using FreeBSD 7.x and have no ahci(4) support :(

I solved the problem by running hdparm -N p1953525168 sdf from linux
livecd, but this is not the fbsd way...

-- 
MATPOCKuH
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: problems with SATA controller after recent RELENG_8 upgrade

[Alexander Motin]

Oliver Lehmann wrote:
 I've just upgraded my 8 from around the 6th of december 2 days ago. Now
 the system won't boot up. When it is going to mount the rootfs, it
 receives some ICRC error and the harddisk gets accessed massivly. The the
 error shown on the screenshot is repeating and repeating. Apart from my
 custom kernel I also compiled and tried the GENERIC kernel with some
 additional modules (ipfw, dummynet, smb, intpm, pcfclock - nothing which
 should interfear)
 The filesystem is labeled with glabel/tunefs.
 
 Could you advise me what to do next? Right now I'm using the old kernel...
 
 Screenshot (where I tried to reach at least single user):
 
http://pics.pofo.de/gallery/v/misc/P1090111.JPG.html

Looks like it was working first, until something happened. I've reread
all Promise related changes and don't see problem there. The only idea I
have is that it could be larger transfer, which was not used before. Try
to apply this patch to get limitation back for these controllers:

--- ata-promise.c.prev  2009-12-15 21:35:43.0 +0200
+++ ata-promise.c   2009-12-15 21:35:24.0 +0200
@@ -957,6 +957,7 @@ ata_promise_mio_dmainit(device_t dev)
 ata_dmainit(dev);
 /* note start and stop are not used here */
 ch-dma.setprd = ata_promise_mio_setprd;
+ch-dma.max_iosize = 65536;
 }


-- 
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Marcel Moolenaar]

On Dec 15, 2009, at 10:36 AM, Jeremy Chadwick wrote:

 Thanks for fixing the problem Karl's reported.  As I've stated in the
 past, I appreciate your efforts and attentiveness to this sort of thing.
 If there's any way I can repay you (Paypal donations, etc.), just let me
 know and I'll do what I can.

Don't worry about me. If people like to do something in return
for what I did, I would like them to donate towards the ports
cluster in general or Mark Linimon (lini...@freebsd.org) in
particular. Mark also puts in a lot of effort to get our bug
database in a decent state, so he's the guy to reward.

FYI,

-- 
Marcel Moolenaar
xcl...@mac.com



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Trouble with drive size detection - 31MB visible size on 1TB drive.

[Jeremy Chadwick]

On Tue, Dec 15, 2009 at 09:44:22PM +0300, KOT MATPOCKuH wrote:
 2009/12/12 Alexander Motin m...@freebsd.org:
  To unlock drive permanently SET MAX ADDRESS ATA command should be used
  (probably the same as Linux uses) with Volatile bit set, to make it not
  restore on power cycle. I don't know how to send this command with
  legacy ata(4), you need some external tool.
 Who knows this some external tool? :)
 As I know hdparm is not ported to *BSD.
 
  With new CAM-based ATA
  probably it can be send via `camcontrol cmd ...`.
 On this machine I'm using FreeBSD 7.x and have no ahci(4) support :(
 
 I solved the problem by running hdparm -N p1953525168 sdf from linux
 livecd, but this is not the fbsd way...

Hmm... interesting.  A couple nights ago I ended up writing some
userland code that expands atacontrol(8) to support display of some
SMART statistics (e.g. atacontrol smart ad10)[1].

So what's this got to do with the above?

ata(4) layer offers an ioctl (IOCATAREQUEST) which literally allows you
to shove raw ATA commands at the disk itself.  This means implementing
the equivalent, i.e. atacontrol cmd, is possible.  Though like with
camcontrol, the implications are risky.

If folks are interested, I could try working on such, though honestly
the argv[] parser in atacontrol(8) needs to be re-written (IMHO).

What I'm saying: folks using straight ata(4) or ataahci(4) would use
atacontrol cmd while folks using ahci(4) would use camcontrol cmd.

Please let me/list know if either of these things are of interest.

[1]: It's hardly done and needs a *lot* of work, but I'll eventually
get it into a state where it could be committed and people could hack on
it/improve it.  It's no where near as defined as smartmontools (re: disk
vendor/model one-offs for attribute parsing and so on), but I figured
FreeBSD users might want something out-of-the-box which might give them
stats which are most commonly focused on (sector reallocation, drive
temperature, high spin-up times, CRC errors, etc.).  I guess you could
say I'm a bit proud of myself given that I was able to figure out how to
accomplish it by looking at some smartmontools source (messy, let me
tell you...) and ata(4) bits (since the ioctls aren't documented).

[2]: Yes, I'm still working on writing that doc that explains how to
read SMART data.  Going to have to end up doing it for work as well...
oh the joys.  :-)

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Jeremy Chadwick]

On Tue, Dec 15, 2009 at 12:16:25PM -0800, Marcel Moolenaar wrote:
 On Dec 15, 2009, at 10:36 AM, Jeremy Chadwick wrote:
 
  Thanks for fixing the problem Karl's reported.  As I've stated in the
  past, I appreciate your efforts and attentiveness to this sort of thing.
  If there's any way I can repay you (Paypal donations, etc.), just let me
  know and I'll do what I can.
 
 Don't worry about me. If people like to do something in return
 for what I did, I would like them to donate towards the ports
 cluster in general or Mark Linimon (lini...@freebsd.org) in
 particular. Mark also puts in a lot of effort to get our bug
 database in a decent state, so he's the guy to reward.

Consider it done -- I'll send Mark a mail later tonight.  :-)

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Dell D830, nVidia and FreeBSD-8/amd64

[John Baldwin]

On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote:
 On Tue, Dec 15, 2009 at 10:18:36AM -0500, John Baldwin wrote:
  On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote:
   On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote:
On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote:
 Hi,
 
 This is a general rehash of a problem that I've been having with my
 Dell Latitude D830 with an nVidia Quadro NVS 140M internal graphics
 card. I've been using the XOrg's vesa driver ever since something 
 in 
  the
 code rendered the nvidia driver inoperable in 7-STABLE sometime mid
 last year. With nVidia's new 195.22 (BETA) drivers, I had hoped that I
 could bypass the problem. Unfortunately, I seem to be experiencing 
 the 
  same
 problem as described in the following thread:
 
http://www.nvnews.net/vbulletin/showthread.php?t=142391
 
 which appears to be implying that something in the kernel is
 interfering with memory allocation. Would it be possible for someone
 with deeper kernel-fu be able to take a look at this issue?

Do you have a verbose dmesg available?
   
   I've attached a dmesg with a verbose boot. I hope this is what you're
   looking for.
  
  Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'?  I suspect 
  that 
  when the bridge allocates the prefetch resource range from the parent it is 
  failing somehow.  For a quick hack try something like this:
 [...]
 
 I've attatched the requested output. Unfortunately, the patch didn't
 result in anything different.

 I/O memory addresses:
 0xdff0-0xe06f (acpi0)
 0xe070-0xe0700fff (cbb0)
 0xe0701000-0xf3ff (root0)

The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges
here conflict with the prefetch BAR for the video adapter.  The cbb0 one I
think is because that range is free when cbb0 needs to allocate a fresh range
of resources.  The real bug is why your BIOS thinks that a system resource is
using 0xe000-0xe06f which conflicts with the nvidia card.  You can
try disabling ACPI's system-resource handling (set
debug.acpi.disabled=sysres from the loader).

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: patch: bad ipv6 neighbor solicitation

[Tom Pusateri]

I didn't think this routing patch was related to the bad neighbor solicitation 
messages as suggested in the subject field but I tried it anyway. It does not 
fix my IPv6 problem. I still get bad neighbor solicitation messages and 
freebsd 8 doesn't respond to 4/5 IPv6 pings.

Thanks,
Tom

On Dec 14, 2009, at 11:53 PM, Li, Qing wrote:

 Please find the more proper fix at
 
   http://people.freebsd.org/~qingli/nd6-patch.diff
 
 I realized I was slightly off in my previous email after
 I spent a bit more time looking through the problem. 
 Both prefixes are present but one was marked off-link due
 to the fact only a single prefix route was installed in
 the routing table (non RADIX_MPATH system).
 
 I evaluated various options to fixing this issue, however, 
 due to the association between NDPRF_ONLINK and the route
 installation, I decided to go with what I have here for
 the time being.
 
 I have verified the fix in my setup. Please apply the
 patch and report back.
 
 Thanks,
 
 -- Qing
 
 
 -Original Message-
 From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
 n...@freebsd.org] On Behalf Of Li, Qing
 Sent: Monday, December 14, 2009 3:00 PM
 To: Dennis Glatting; JASSAL Aman
 Cc: freebsd-...@freebsd.org
 Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
 
 
 You don't need to perform all that route-foo. I believe the root cause
 of
 this issue may be due to a bit of regression in the IPv6 prefix
 management
 code, and I am in the process of putting together a permanent fix.
 
 The issue as it stands today, is due to how the prefix was inserted in
 the first place. Since bce0 was configured first, the interface
 associated
 with the prefix is bce0. Later the reference count on the prefix is
 simply incremented when bce1 configures another IPv6 address of the
 same prefix.
 
 When ND6 NS arrives for bce1, due to the interface mismatch of the
 prefix
 interface against the input interface, the NS packet was considered
 invalid and thus dropped.
 
 Again, in case you didn't see my earlier reply, try the temporary hack
 at
http://people.freebsd.org/~qingli/nd6-ns.diff
 
 until I commit a permanent patch. The problem was easily reproducible
 and
 I have verified with limited unit testing the patch works.
 
 -- Qing
 
 
 -Original Message-
 From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting
 Sent: Mon 12/14/2009 2:03 PM
 To: JASSAL Aman
 Cc: freebsd-...@freebsd.org
 Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd)
 
 
 Thanks. Responses in-line.
 
 
 
 On Mon, 14 Dec 2009, JASSAL Aman wrote:
 
 Hello Mr.Glatting,
 
 Not that I'm an IPv6 genius, but at first sight your problem seems
 to
 be a
 route-related. I've put comments in-line.
 
 
 Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit :
 
 
 Elmer# netstat -rn
 Routing tables
 
 
 Internet6:
 Destination   Gateway
 Flags
 Netif Expire
 ::/96 ::1
 UGRS
 lo0  = default   fd7c:3f2b:e791:1::1
 UGSbce0
 ::1   ::1   UH
 lo0 :::0.0.0.0/96 ::1
 UGRS
 lo0 fd7c:3f2b:e791:1::/64 link#1
 U
 bce0 fd7c:3f2b:e791:1::ac13:a0alink#1
 UHS
 lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2
 UHS
 lo0 fe80::/10 ::1
 UGRS
 lo0 fe80::%bce0/64link#1
 U
 bce0 fe80::213:72ff:fe60:ac52%bce0 link#1
 UHS
 lo0 fe80::%bce1/64link#2
 U
 bce1 fe80::213:72ff:fe60:ac50%bce1 link#2
 UHS
 lo0 fe80::%lo0/64 link#3
 U
 lo0 fe80::1%lo0   link#3
 UHS
 lo0 ff01:1::/32   fe80::213:72ff:fe60:ac52%bce0
 U
 bce0 ff01:2::/32
 fd7c:3f2b:e791:1:0:1:ac13:a0a
 U
 bce1 ff01:3::/32   ::1
 U
 lo0 ff02::/16 ::1
 UGRS
 lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0
 U
 bce0 ff02::%bce1/32
 fd7c:3f2b:e791:1:0:1:ac13:a0a
 U
 bce1 ff02::%lo0/32 ::1
 U
 lo0
 
 
 Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I
 was
 expecting bce1 rather than lo0, I suppose you were as well :) If I'm
 not
 mistaken, the packets emanating from bce1 go to the loopback
 interface,
 thus not really going out. You can try specifying the route manually
 with route add *your parameters* or even set it in /etc/rc.conf so
 that it's loaded at boot-time. There's no reason why among 2
 physical
 interfaces sharing the same fabric, one can ship packets out and the
 other can't.
 
 
 I was wondering about the route however I haven't figured out the
 trick
 to
 get what I want. For example:
 
 Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a
 delete host fd7c:3f2b:e791:1:0:1:ac13:a0a
 
 Elmer# route add
 -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1
 route: writing to routing socket: File exists
 add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: 

RE: patch: bad ipv6 neighbor solicitation

[Li, Qing]

Thanks for reporting back. I asked you for a routing table dump
in my previous email, would you mind emailing it to me privately?

-- Qing


 -Original Message-
 From: Tom Pusateri [mailto:pusat...@bangj.com]
 Sent: Tuesday, December 15, 2009 1:28 PM
 To: Li, Qing
 Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org
 Subject: Re: patch: bad ipv6 neighbor solicitation
 
 I didn't think this routing patch was related to the bad neighbor
 solicitation messages as suggested in the subject field but I tried
it
 anyway. It does not fix my IPv6 problem. I still get bad neighbor
 solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6
pings.
 
 Thanks,
 Tom
 
 On Dec 14, 2009, at 11:53 PM, Li, Qing wrote:
 
  Please find the more proper fix at
 
  http://people.freebsd.org/~qingli/nd6-patch.diff
 
  I realized I was slightly off in my previous email after
  I spent a bit more time looking through the problem.
  Both prefixes are present but one was marked off-link due
  to the fact only a single prefix route was installed in
  the routing table (non RADIX_MPATH system).
 
  I evaluated various options to fixing this issue, however,
  due to the association between NDPRF_ONLINK and the route
  installation, I decided to go with what I have here for
  the time being.
 
  I have verified the fix in my setup. Please apply the
  patch and report back.
 
  Thanks,
 
  -- Qing
 
 
  -Original Message-
  From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
  n...@freebsd.org] On Behalf Of Li, Qing
  Sent: Monday, December 14, 2009 3:00 PM
  To: Dennis Glatting; JASSAL Aman
  Cc: freebsd-...@freebsd.org
  Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)
 
 
  You don't need to perform all that route-foo. I believe the root
 cause
  of
  this issue may be due to a bit of regression in the IPv6 prefix
  management
  code, and I am in the process of putting together a permanent fix.
 
  The issue as it stands today, is due to how the prefix was inserted
 in
  the first place. Since bce0 was configured first, the interface
  associated
  with the prefix is bce0. Later the reference count on the prefix is
  simply incremented when bce1 configures another IPv6 address of the
  same prefix.
 
  When ND6 NS arrives for bce1, due to the interface mismatch of the
  prefix
  interface against the input interface, the NS packet was considered
  invalid and thus dropped.
 
  Again, in case you didn't see my earlier reply, try the temporary
 hack
  at
 http://people.freebsd.org/~qingli/nd6-ns.diff
 
  until I commit a permanent patch. The problem was easily
 reproducible
  and
  I have verified with limited unit testing the patch works.
 
  -- Qing
 
 
  -Original Message-
  From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting
  Sent: Mon 12/14/2009 2:03 PM
  To: JASSAL Aman
  Cc: freebsd-...@freebsd.org
  Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd)
 
 
  Thanks. Responses in-line.
 
 
 
  On Mon, 14 Dec 2009, JASSAL Aman wrote:
 
  Hello Mr.Glatting,
 
  Not that I'm an IPv6 genius, but at first sight your problem seems
  to
  be a
  route-related. I've put comments in-line.
 
 
  Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit :
 
 
  Elmer# netstat -rn
  Routing tables
 
 
  Internet6:
  Destination   Gateway
  Flags
  Netif Expire
  ::/96 ::1
  UGRS
  lo0  = default   fd7c:3f2b:e791:1::1
  UGSbce0
  ::1   ::1
UH
  lo0 :::0.0.0.0/96 ::1
  UGRS
  lo0 fd7c:3f2b:e791:1::/64 link#1
  U
  bce0 fd7c:3f2b:e791:1::ac13:a0alink#1
  UHS
  lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2
  UHS
  lo0 fe80::/10 ::1
  UGRS
  lo0 fe80::%bce0/64link#1
  U
  bce0 fe80::213:72ff:fe60:ac52%bce0 link#1
  UHS
  lo0 fe80::%bce1/64link#2
  U
  bce1 fe80::213:72ff:fe60:ac50%bce1 link#2
  UHS
  lo0 fe80::%lo0/64 link#3
  U
  lo0 fe80::1%lo0   link#3
  UHS
  lo0 ff01:1::/32
 fe80::213:72ff:fe60:ac52%bce0
  U
  bce0 ff01:2::/32
  fd7c:3f2b:e791:1:0:1:ac13:a0a
  U
  bce1 ff01:3::/32   ::1
  U
  lo0 ff02::/16 ::1
  UGRS
  lo0 ff02::%bce0/32
 fe80::213:72ff:fe60:ac52%bce0
  U
  bce0 ff02::%bce1/32
  fd7c:3f2b:e791:1:0:1:ac13:a0a
  U
  bce1 ff02::%lo0/32 ::1
  U
  lo0
 
 
  Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I
  was
  expecting bce1 rather than lo0, I suppose you were as well :) If
 I'm
  not
  mistaken, the packets emanating from bce1 go to the loopback
  interface,
  thus not really going out. You can try specifying the route
 manually
  with route add *your parameters* or even set it in /etc/rc.conf
 so
  that it's loaded at boot-time. There's no reason why among 2
  physical
  interfaces sharing the same 

RE: patch: bad ipv6 neighbor solicitation

[Li, Qing]

Thanks for sending me the routing table output.

Actually I believe both your problems are indeed related to the 
prefix route. 

I was able to reproduce Dennis Glatting's problem, which was due
to one of the prefix entry being off-link.

In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad
disappeared and is not in the routing table. If you add the route
by hand the problem should go away.

I guess the question is what triggered the prefix route deletion.

-- Qing


 -Original Message-
 From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
 sta...@freebsd.org] On Behalf Of Li, Qing
 Sent: Tuesday, December 15, 2009 1:46 PM
 To: Tom Pusateri
 Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org
 Subject: RE: patch: bad ipv6 neighbor solicitation
 
 Thanks for reporting back. I asked you for a routing table dump
 in my previous email, would you mind emailing it to me privately?
 
 -- Qing
 
 
  -Original Message-
  From: Tom Pusateri [mailto:pusat...@bangj.com]
  Sent: Tuesday, December 15, 2009 1:28 PM
  To: Li, Qing
  Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org
  Subject: Re: patch: bad ipv6 neighbor solicitation
 
  I didn't think this routing patch was related to the bad neighbor
  solicitation messages as suggested in the subject field but I tried
 it
  anyway. It does not fix my IPv6 problem. I still get bad neighbor
  solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6
 pings.
 
  Thanks,
  Tom
 
  On Dec 14, 2009, at 11:53 PM, Li, Qing wrote:
 
   Please find the more proper fix at
  
 http://people.freebsd.org/~qingli/nd6-patch.diff
  
   I realized I was slightly off in my previous email after
   I spent a bit more time looking through the problem.
   Both prefixes are present but one was marked off-link due
   to the fact only a single prefix route was installed in
   the routing table (non RADIX_MPATH system).
  
   I evaluated various options to fixing this issue, however,
   due to the association between NDPRF_ONLINK and the route
   installation, I decided to go with what I have here for
   the time being.
  
   I have verified the fix in my setup. Please apply the
   patch and report back.
  
   Thanks,
  
   -- Qing
  
  
   -Original Message-
   From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
   n...@freebsd.org] On Behalf Of Li, Qing
   Sent: Monday, December 14, 2009 3:00 PM
   To: Dennis Glatting; JASSAL Aman
   Cc: freebsd-...@freebsd.org
   Subject: RE: Understanding multiple IPv6 interfaces under 8.0
(fwd)
  
  
   You don't need to perform all that route-foo. I believe the root
  cause
   of
   this issue may be due to a bit of regression in the IPv6 prefix
   management
   code, and I am in the process of putting together a permanent
fix.
  
   The issue as it stands today, is due to how the prefix was
 inserted
  in
   the first place. Since bce0 was configured first, the interface
   associated
   with the prefix is bce0. Later the reference count on the prefix
 is
   simply incremented when bce1 configures another IPv6 address of
 the
   same prefix.
  
   When ND6 NS arrives for bce1, due to the interface mismatch of
the
   prefix
   interface against the input interface, the NS packet was
 considered
   invalid and thus dropped.
  
   Again, in case you didn't see my earlier reply, try the temporary
  hack
   at
  http://people.freebsd.org/~qingli/nd6-ns.diff
  
   until I commit a permanent patch. The problem was easily
  reproducible
   and
   I have verified with limited unit testing the patch works.
  
   -- Qing
  
  
   -Original Message-
   From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting
   Sent: Mon 12/14/2009 2:03 PM
   To: JASSAL Aman
   Cc: freebsd-...@freebsd.org
   Subject: Re: Understanding multiple IPv6 interfaces under 8.0
(fwd)
  
  
   Thanks. Responses in-line.
  
  
  
   On Mon, 14 Dec 2009, JASSAL Aman wrote:
  
   Hello Mr.Glatting,
  
   Not that I'm an IPv6 genius, but at first sight your problem
 seems
   to
   be a
   route-related. I've put comments in-line.
  
  
   Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit :
  
  
   Elmer# netstat -rn
   Routing tables
  
  
   Internet6:
   Destination   Gateway
   Flags
   Netif Expire
   ::/96 ::1
   UGRS
   lo0  = default   fd7c:3f2b:e791:1::1
   UGSbce0
   ::1   ::1
 UH
   lo0 :::0.0.0.0/96 ::1
   UGRS
   lo0 fd7c:3f2b:e791:1::/64 link#1
   U
   bce0 fd7c:3f2b:e791:1::ac13:a0alink#1
   UHS
   lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2
   UHS
   lo0 fe80::/10 ::1
   UGRS
   lo0 fe80::%bce0/64link#1
   U
   bce0 fe80::213:72ff:fe60:ac52%bce0 link#1
   UHS
   lo0 fe80::%bce1/64link#2
   U
   bce1 fe80::213:72ff:fe60:ac50%bce1 link#2
   UHS
   lo0 fe80::%lo0/64  

update to 8.0-RELEASE -- partition gone

[Marian Hettwer]

Hi Folks,

today I did an update from 7.2-RELEASE-p4 to 8.0-RELEASE using 
freebsd-update.
Everything went smooth, apart from the fact that I can't mount my second 
disk.

It's all a bit puzzling...
Here are the facts:

[r...@talisker ~]# cat /etc/fstab   
# DeviceMountpointFStypeOptionsDumpPass#

/dev/ad4s2bnoneswapswOO
/dev/ad4s1a/ufsrw11
/dev/ad4s2a/tmpufsrw22
/dev/ad4s2d/varufsrw22
/dev/ad4s2e/usrufsrw22
/dev/ad8s1a/BACKUPufsrw22
/dev/acd0/cdromcd9660ro,noauto00
linproc/compat/linux/proclinprocfsrw 00

The offending entry which isn't mountable anymore is ad8s1.
[r...@talisker ~]# sysctl kern.disks
kern.disks: ad8 ad4

fdisk and bsdlabel are showing my s1a partition/slice:
[r...@talisker ~]# fdisk ad8
*** Working on device /dev/ad8 ***
parameters extracted from in-core disklabel are:
cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
   start 63, size 781422705 (381554 Meg), flag 80 (active)
   beg: cyl 0/ head 1/ sector 1;
   end: cyl 52/ head 15/ sector 63
The data for partition 2 is:
UNUSED
The data for partition 3 is:
UNUSED
The data for partition 4 is:
UNUSED
[r...@talisker ~]# bsdlabel ad8
# /dev/ad8:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
 a: 781422752   16unused0 0  
 c: 7814227680unused0 0 # raw part, 
don't edit


but:
[r...@talisker ~]# mount /dev/ad8s1a /BACKUP/
mount: /dev/ad8s1a : No such file or directory

And in fact:
[r...@talisker ~]# ls -l /dev/ad8*
crw-r-  1 root  operator0,  91 Dec 15 17:58 /dev/ad8
crw-r-  1 root  operator0,  96 Dec 15 17:58 /dev/ad8a

Huu? What's going on here? Where is s1?
Never seen that before... (and I'm using FreeBSD since 4.0-RELEASE).
and this mount obviously won't work either:
[r...@talisker ~]# mount /dev/ad8a /BACKUP/
mount: /dev/ad8a : Invalid argument

Anybody any idea how to recover here?
The server is unluckily remote and in production. A downgrade back to 
7.2 would be kinda difficult. I'd like to avoid that.


Ideas anyone?

Thanks in advance,
Marian

PS.:
dmesg: http://crivens.terrorteam.de/~rabauke/FreeBSD/dmesg-8.0-release.txt
[r...@talisker ~]# uname -rms
FreeBSD 8.0-RELEASE i386

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: freebsd / gpt boot

[Adam Jacob Muller]

On Dec 14, 2009, at 10:46 AM, Robert Noland wrote:

 On Sun, 2009-12-13 at 23:21 +0100, Rolf G Nielsen wrote:
 Adam Jacob Muller wrote:
 Hi,
 I'm trying to setup a system with a very large RAID array (total ~10TB), I 
 would ideally like to have the system boot directly off that 10TB array, so 
 i'm trying to get the system setup with GPT but running into an issue.
 
 
 The initial pre-loader (boot0 I think? -- i'm not sure what this is called) 
 is unable to find loader at /boot/loader nor can it load /boot/kernel/kernel
 
 
 Is the partitioning done correctly (have you created a small boot 
 partition, 15 sectors is enough for booting from ufs, but the tutorials 
 I've found deal mainly with booting from zfs and they recommend 128 
 sectors to make future bootcode changes easier)?
 
 You will need to be doing all of this from a current 8-STABLE.  One bug
 in dealing with larger zfs raidz volumes was fixed and made it into 8.0.
 Another, which deals with GPT/ZFS and large volumes did not make it and
 only exists in 8-STABLE, iirc.  Also, with the gptzfsboot code from
 -STABLE, it will request to load /boot/zfsloader by default (and
 LOADER_ZFS_SUPPORT is no longer required).
 
 gpart add -b 34 -s 128 -t freebsd-boot -i 1 da0
 
 Have you embedded the correct boot code?
 
 gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0
 (for booting from ufs).
 
 or
 
 gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
 (for booting from zfs).
 
 You may also need to set it active by
 
 gpart set -a active -i 1 da0
 
 The above step is no longer needed on -STABLE, the pmbr will be marked
 active when you install bootcode.

Robert,
Do either of these bugs affect GPT/UFS, which is what I am using here.

These bugs are affecting the actual older versions of the tools (IE using the 
gpart from an 8.0-pre or earlier could cause issues like this)?

Also, perhaps not coincidentally, booting the FreeBSD memstick image produces 
the same error (boot0 can't find loader).


-Adam

 
 robert.
 
 And of course, substitute your arrays device node for da0 in my examples.
 
 Copying /boot/loader to /loader allows me to enter /loader at the boot: 
 prompt and the loader will load, however, its unable to load the kernel.
 
 If I do an ls at the loader prompt I can see boot listed as a directory 
 (with a d before it)
 Trying to do ls boot inexplicably it says boot: not a directory
 
 re-applying my /boot/loader.conf settings (for some reason 
 vfs.root.mountfrom=ufs:/dev/label/root is required, or else I get a 
 mountroot) and then:
 load /kernel
 boot
 
 does work, and lets the system boot normally and everything is as expected 
 (/boot is a directory etc).
 
 Anyone have any ideas about either of these things (the vfs.root.mountfrom 
 is minor i guess but i'm curious if they are related?)
 
 Thanks in advance,
 
 -Adam
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 
 
 
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 -- 
 Robert Noland rnol...@freebsd.org
 FreeBSD
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

iSCSI initiator and Dell PowerVault MD3000i

[Miroslav Lachman]

Hi all,
I am playing with iscsi_initiator on FreeBSD 7-STABLE and Dell 
PowerVault MD3000i. This is the first time I am testing iSCSI...


Does anyone have FreeBSD's iSCSI initiator in production / heavy load? 
Or does somebody have experiences with Dell MD3000i?


One thing is poor performance ~ 60 - 70MB/s depending on RAID level 
used. (poor performance compared to plain SATA disk which have 110MB/s - 
both tested for reading as it is our planned load - multimedia streaming 
and downloads)



The other thing is some problem with compatibility of initiator and Dell 
MD3000i.


If I setup RAID 5 'Disk Group' consisted of 4x 1TB SATA drives (in 
MD3000i) and then created for example 2 'Virtual Disks', both are 
detected by iscontrol and added to /dev/ as da0 and da1, but da1 spams 
log with messages like this:


Dec 15 04:00:38 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0
Dec 15 04:00:38 dust kernel: da0: DELL MD3000i 0735 Fixed Direct 
Access SCSI-5 device

Dec 15 04:00:38 dust kernel: da1 at iscsi0 bus 0 target 0 lun 1
Dec 15 04:00:38 dust kernel: da1: DELL MD3000i 0735 Fixed Direct 
Access SCSI-5 device
Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough 
device found at 0:0:2
Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough 
device found at 0:0:3
Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(6)/WRITE(6) not 
supported, increasing minimum_cmd_size to 10.
Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 
0 0 0 0 1 0
Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status 
Error
Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check 
Condition

Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1
Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC
Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Unretryable error
Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 c 
7f df ff 0 0 1 0
Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status 
Error
Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check 
Condition

Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1
Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC
Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Unretryable error
Dec 15 04:00:41 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 
0 0 0 0 1 0


The message repeated many times.

If I created more 'Virtual Disks' (7 for example), 3 of them are 
producing same errors (da1, da3, da5)


If there is only one 'Virtual Disk', it seems fine... until I configured 
second path to the virtual disk as I want to try gmultipath or geom_fox 
(MD3000i is dual controller with 4 NICs), then second session produces 
same errors.


First path - OK:

Dec 15 22:47:57 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0
Dec 15 22:47:57 dust kernel: da0: DELL MD3000i 0735 Fixed Direct 
Access SCSI-5 device
Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough 
device found at 0:0:1
Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough 
device found at 0:0:2
Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough 
device found at 0:0:3



Second path - error:

Dec 15 22:48:04 dust kernel: da1 at iscsi0 bus 0 target 1 lun 0
Dec 15 22:48:04 dust kernel: da1: DELL MD3000i 0735 Fixed Direct 
Access SCSI-5 device
Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(6)/WRITE(6) not 
supported, increasing minimum_cmd_size to 10.
Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 
0 0 0 0 1 0
Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status 
Error
Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check 
Condition

Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1
Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC
Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Unretryable error
Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough 
device found at 0:1:1
Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough 
device found at 0:1:2
Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough 
device found at 0:1:3
Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): READ(16). CDB: 88 0 0 0 
0 1 5d 21 1f ff 0 0 0 1 0 0
Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status 
Error
Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check 
Condition

Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1
Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC
Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Unretryable error
Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 
0 0 0 0 1 0
Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status 
Error
Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check 
Condition

Dec 15 

Re: update to 8.0-RELEASE -- partition gone

[Steven Friedrich]

On Tuesday 15 December 2009 04:42:06 pm Marian Hettwer wrote:
 Hi Folks,
 
 today I did an update from 7.2-RELEASE-p4 to 8.0-RELEASE using
 freebsd-update.
 Everything went smooth, apart from the fact that I can't mount my second
 disk.
 It's all a bit puzzling...
 Here are the facts:
 
 [r...@talisker ~]# cat /etc/fstab
 # DeviceMountpointFStypeOptionsDumpPass#
 /dev/ad4s2bnoneswapswOO
 /dev/ad4s1a/ufsrw11
 /dev/ad4s2a/tmpufsrw22
 /dev/ad4s2d/varufsrw22
 /dev/ad4s2e/usrufsrw22
 /dev/ad8s1a/BACKUPufsrw22
 /dev/acd0/cdromcd9660ro,noauto00
 linproc/compat/linux/proclinprocfsrw 00
 
 The offending entry which isn't mountable anymore is ad8s1.
 [r...@talisker ~]# sysctl kern.disks
 kern.disks: ad8 ad4
 
 fdisk and bsdlabel are showing my s1a partition/slice:
 [r...@talisker ~]# fdisk ad8
 *** Working on device /dev/ad8 ***
 parameters extracted from in-core disklabel are:
 cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)
 
 Figures below won't work with BIOS for partitions not in cyl 1
 parameters to be used for BIOS calculations are:
 cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)
 
 Media sector size is 512
 Warning: BIOS sector numbering starts with sector 1
 Information from DOS bootblock is:
 The data for partition 1 is:
 sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
 start 63, size 781422705 (381554 Meg), flag 80 (active)
 beg: cyl 0/ head 1/ sector 1;
 end: cyl 52/ head 15/ sector 63
 The data for partition 2 is:
 UNUSED
 The data for partition 3 is:
 UNUSED
 The data for partition 4 is:
 UNUSED
 [r...@talisker ~]# bsdlabel ad8
 # /dev/ad8:
 8 partitions:
 #size   offsetfstype   [fsize bsize bps/cpg]
   a: 781422752   16unused0 0
   c: 7814227680unused0 0 # raw part,
 don't edit
 
 but:
 [r...@talisker ~]# mount /dev/ad8s1a /BACKUP/
 mount: /dev/ad8s1a : No such file or directory
 
 And in fact:
 [r...@talisker ~]# ls -l /dev/ad8*
 crw-r-  1 root  operator0,  91 Dec 15 17:58 /dev/ad8
 crw-r-  1 root  operator0,  96 Dec 15 17:58 /dev/ad8a
 
 Huu? What's going on here? Where is s1?
 Never seen that before... (and I'm using FreeBSD since 4.0-RELEASE).
 and this mount obviously won't work either:
 [r...@talisker ~]# mount /dev/ad8a /BACKUP/
 mount: /dev/ad8a : Invalid argument
 
 Anybody any idea how to recover here?
 The server is unluckily remote and in production. A downgrade back to
 7.2 would be kinda difficult. I'd like to avoid that.
 
 Ideas anyone?
 
 Thanks in advance,
 Marian
 
 PS.:
 dmesg: http://crivens.terrorteam.de/~rabauke/FreeBSD/dmesg-8.0-release.txt
 [r...@talisker ~]# uname -rms
 FreeBSD 8.0-RELEASE i386
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 
FreeBSD 8.0 no longer supports dangerously dedicated disks.
Is this your issue?
fdisk output appears to indicate that your disk has a partition table, but I 
never looked at one with fdisk that was dedicated...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: patch: bad ipv6 neighbor solicitation

[Tom Pusateri]

You are correct. I added the route and it works fine. 

route add -inet6 2610:28:1800:4001::/64 -iface em0

Thanks,
Tom

On Dec 15, 2009, at 5:00 PM, Li, Qing wrote:

 Thanks for sending me the routing table output.
 
 Actually I believe both your problems are indeed related to the 
 prefix route. 
 
 I was able to reproduce Dennis Glatting's problem, which was due
 to one of the prefix entry being off-link.
 
 In your case the prefix route for 2610:28:1800:4001:20e:cff:fe9f:faad
 disappeared and is not in the routing table. If you add the route
 by hand the problem should go away.
 
 I guess the question is what triggered the prefix route deletion.
 
 -- Qing
 
 
 -Original Message-
 From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
 sta...@freebsd.org] On Behalf Of Li, Qing
 Sent: Tuesday, December 15, 2009 1:46 PM
 To: Tom Pusateri
 Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org
 Subject: RE: patch: bad ipv6 neighbor solicitation
 
 Thanks for reporting back. I asked you for a routing table dump
 in my previous email, would you mind emailing it to me privately?
 
 -- Qing
 
 
 -Original Message-
 From: Tom Pusateri [mailto:pusat...@bangj.com]
 Sent: Tuesday, December 15, 2009 1:28 PM
 To: Li, Qing
 Cc: freebsd-...@freebsd.org; freebsd-stable@freebsd.org
 Subject: Re: patch: bad ipv6 neighbor solicitation
 
 I didn't think this routing patch was related to the bad neighbor
 solicitation messages as suggested in the subject field but I tried
 it
 anyway. It does not fix my IPv6 problem. I still get bad neighbor
 solicitation messages and freebsd 8 doesn't respond to 4/5 IPv6
 pings.
 
 Thanks,
 Tom
 
 On Dec 14, 2009, at 11:53 PM, Li, Qing wrote:
 
 Please find the more proper fix at
 
http://people.freebsd.org/~qingli/nd6-patch.diff
 
 I realized I was slightly off in my previous email after
 I spent a bit more time looking through the problem.
 Both prefixes are present but one was marked off-link due
 to the fact only a single prefix route was installed in
 the routing table (non RADIX_MPATH system).
 
 I evaluated various options to fixing this issue, however,
 due to the association between NDPRF_ONLINK and the route
 installation, I decided to go with what I have here for
 the time being.
 
 I have verified the fix in my setup. Please apply the
 patch and report back.
 
 Thanks,
 
 -- Qing
 
 
 -Original Message-
 From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
 n...@freebsd.org] On Behalf Of Li, Qing
 Sent: Monday, December 14, 2009 3:00 PM
 To: Dennis Glatting; JASSAL Aman
 Cc: freebsd-...@freebsd.org
 Subject: RE: Understanding multiple IPv6 interfaces under 8.0
 (fwd)
 
 
 You don't need to perform all that route-foo. I believe the root
 cause
 of
 this issue may be due to a bit of regression in the IPv6 prefix
 management
 code, and I am in the process of putting together a permanent
 fix.
 
 The issue as it stands today, is due to how the prefix was
 inserted
 in
 the first place. Since bce0 was configured first, the interface
 associated
 with the prefix is bce0. Later the reference count on the prefix
 is
 simply incremented when bce1 configures another IPv6 address of
 the
 same prefix.
 
 When ND6 NS arrives for bce1, due to the interface mismatch of
 the
 prefix
 interface against the input interface, the NS packet was
 considered
 invalid and thus dropped.
 
 Again, in case you didn't see my earlier reply, try the temporary
 hack
 at
   http://people.freebsd.org/~qingli/nd6-ns.diff
 
 until I commit a permanent patch. The problem was easily
 reproducible
 and
 I have verified with limited unit testing the patch works.
 
 -- Qing
 
 
 -Original Message-
 From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting
 Sent: Mon 12/14/2009 2:03 PM
 To: JASSAL Aman
 Cc: freebsd-...@freebsd.org
 Subject: Re: Understanding multiple IPv6 interfaces under 8.0
 (fwd)
 
 
 Thanks. Responses in-line.
 
 
 
 On Mon, 14 Dec 2009, JASSAL Aman wrote:
 
 Hello Mr.Glatting,
 
 Not that I'm an IPv6 genius, but at first sight your problem
 seems
 to
 be a
 route-related. I've put comments in-line.
 
 
 Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit :
 
 
 Elmer# netstat -rn
 Routing tables
 
 
 Internet6:
 Destination   Gateway
 Flags
 Netif Expire
 ::/96 ::1
 UGRS
 lo0  = default   fd7c:3f2b:e791:1::1
 UGSbce0
 ::1   ::1
 UH
 lo0 :::0.0.0.0/96 ::1
 UGRS
 lo0 fd7c:3f2b:e791:1::/64 link#1
 U
 bce0 fd7c:3f2b:e791:1::ac13:a0alink#1
 UHS
 lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2
 UHS
 lo0 fe80::/10 ::1
 UGRS
 lo0 fe80::%bce0/64link#1
 U
 bce0 fe80::213:72ff:fe60:ac52%bce0 link#1
 UHS
 lo0 fe80::%bce1/64link#2
 U
 bce1 fe80::213:72ff:fe60:ac50%bce1 link#2
 UHS
 lo0 fe80::%lo0/64 link#3
 U
 lo0 

Re: update to 8.0-RELEASE -- partition gone

[Marcel Moolenaar]

On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
 
 FreeBSD 8.0 no longer supports dangerously dedicated disks.

This is not true. The problem is that sysinstall creates an invalid
dangerously dedicated disk, as demonstrated by doing:
# fdisk ad8
(shows FreeBSD slice information)

# bsdlabel ad8
(shows valid but empty disk label)

Marian just needs to wipe out the second sector on the disk to
remove the BSD disklabel that prevents the kernel from using
the master boot record in the 1st sector. This exposes ad8s1.
This then will pick up the BSD disklabel in sector 65 (i.e.
the second sector in slice 1) to give ad8s1a...

 fdisk output appears to indicate that your disk has a partition table, but I 
 never looked at one with fdisk that was dedicated...

fdisk may or may not show partitions. Typically there should not
be any, because it's the disklabel in sector 2 that holds the
partition information. The MBR in the first sector is there only
for the BIOS: you can't boot without one.

-- 
Marcel Moolenaar
xcl...@mac.com



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

net/mpd5, ppp, proxy-arp issues

[Li, Qing]

Hi,

Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read through the
various postings and the problems seem to be:

1. Unable to add proxy-arp entries for the remote ppp clients.

2. Log showing ifa_add_loopback_route: insertion failed causing 
   some userland applications to fail.

May I ask that you try applying patch

  http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff

and report back if the patch fixes your problems. And if not, 
please describe what additional issues you are having.

Thanks,

-- Qing


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: update to 8.0-RELEASE -- partition gone

[Ben Morrow]

Quoth Marcel Moolenaar xcl...@mac.com:
 On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
  
  FreeBSD 8.0 no longer supports dangerously dedicated disks.
 
 This is not true. The problem is that sysinstall creates an invalid
 dangerously dedicated disk, as demonstrated by doing:
   # fdisk ad8
   (shows FreeBSD slice information)
 
   # bsdlabel ad8
   (shows valid but empty disk label)
 
 Marian just needs to wipe out the second sector on the disk to
 remove the BSD disklabel that prevents the kernel from using
 the master boot record in the 1st sector. This exposes ad8s1.
 This then will pick up the BSD disklabel in sector 65 (i.e.
 the second sector in slice 1) to give ad8s1a...

Are you able to clarify exactly what is no longer working in 8? I've
read things here and there about dangerously dedicated disks no longer
being supported, but no detail about what exactly had changed. You seem
to be implying here that there is only a problem if there are invalid
and/or overlapping labels on the disk; elsewhere I have read that disks
without an MBR aren't supported at all (I presume the faked-up MBR on a
GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they
be picked up by 8, or would I have to repartition slightly smaller with
a useless MBR slice in front?

Ben

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: update to 8.0-RELEASE -- partition gone

[Xin LI]

On Tue, Dec 15, 2009 at 4:08 PM, Ben Morrow b...@morrow.me.uk wrote:
 Quoth Marcel Moolenaar xcl...@mac.com:
 On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
 
  FreeBSD 8.0 no longer supports dangerously dedicated disks.

 This is not true. The problem is that sysinstall creates an invalid
 dangerously dedicated disk, as demonstrated by doing:
       # fdisk ad8
       (shows FreeBSD slice information)

       # bsdlabel ad8
       (shows valid but empty disk label)

 Marian just needs to wipe out the second sector on the disk to
 remove the BSD disklabel that prevents the kernel from using
 the master boot record in the 1st sector. This exposes ad8s1.
 This then will pick up the BSD disklabel in sector 65 (i.e.
 the second sector in slice 1) to give ad8s1a...

 Are you able to clarify exactly what is no longer working in 8? I've
 read things here and there about dangerously dedicated disks no longer
 being supported, but no detail about what exactly had changed. You seem
 to be implying here that there is only a problem if there are invalid
 and/or overlapping labels on the disk; elsewhere I have read that disks
 without an MBR aren't supported at all (I presume the faked-up MBR on a
 GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they
 be picked up by 8, or would I have to repartition slightly smaller with
 a useless MBR slice in front?

My $0.02: what about labelling them, say, tunefs -L on UFS partitions,
and glabel for swap, then change corresponding entry in fstab.  Say:

 - Start into single user
 - tunefs -L root /
 - reboot into single user --- reboot required after tuning /
 - mount -u /; mount -a
 - vi /etc/fstab and change /dev/ad0a to /dev/ufs/root
 - umount -a
 - tunefs -L other partitions
 - mount -a
 - vi /etc/fstab and change the rest
 - reboot

Cheers,
-- 
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: update to 8.0-RELEASE -- partition gone

[Marcel Moolenaar]

On Dec 15, 2009, at 4:08 PM, Ben Morrow wrote:

 Quoth Marcel Moolenaar xcl...@mac.com:
 On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
 
 FreeBSD 8.0 no longer supports dangerously dedicated disks.
 
 This is not true. The problem is that sysinstall creates an invalid
 dangerously dedicated disk, as demonstrated by doing:
  # fdisk ad8
  (shows FreeBSD slice information)
 
  # bsdlabel ad8
  (shows valid but empty disk label)
 
 Marian just needs to wipe out the second sector on the disk to
 remove the BSD disklabel that prevents the kernel from using
 the master boot record in the 1st sector. This exposes ad8s1.
 This then will pick up the BSD disklabel in sector 65 (i.e.
 the second sector in slice 1) to give ad8s1a...
 
 Are you able to clarify exactly what is no longer working in 8?

Everything is working, but behaviour has changed for invalid
disks. Invalid disks are disks with conflicting partitioning
information. In FreeBSD 8.x the behaviour is deterministic
and for the broken dangerously dedicated disks that sysinstall
creates this means that we use the partition information in
the BSD disklabel. In FreeBSD 7.x this could come from either
the MBR or the BSD disklabel, with the MBR the more common
scenario.

 You seem
 to be implying here that there is only a problem if there are invalid
 and/or overlapping labels on the disk; elsewhere I have read that disks
 without an MBR aren't supported at all (I presume the faked-up MBR on a
 GPT disk counts).

Disks without an MBR are supported.

 If I currently have a working ad2{b,c,d,e}, will they
 be picked up by 8, or would I have to repartition slightly smaller with
 a useless MBR slice in front?

Yes, if you have ad2a and not ad2s1a, then you have a
proper dangerously dedicated disk and FreeBSD 8.x will
work correctly with your disk.

If you installed dangerously dedicated and ended up
with ad0s1a (note the s1), then you have an invalid
partitioning and FreeBSD 8.x will not give you what
you've been getting on FreeBSD 7.x. Most of the time
you only need to wipe out the second sector on the
disk to clean it up and have FreeBSD 8.x also give
you ad0s1a.

-- 
Marcel Moolenaar
xcl...@mac.com



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: update to 8.0-RELEASE -- partition gone

[Ben Morrow]

Quoth Xin LI delp...@gmail.com:
 On Tue, Dec 15, 2009 at 4:08 PM, Ben Morrow b...@morrow.me.uk wrote:
 
  Are you able to clarify exactly what is no longer working in 8? I've
  read things here and there about dangerously dedicated disks no longer
  being supported, but no detail about what exactly had changed. You seem
  to be implying here that there is only a problem if there are invalid
  and/or overlapping labels on the disk; elsewhere I have read that disks
  without an MBR aren't supported at all (I presume the faked-up MBR on a
  GPT disk counts). If I currently have a working ad2{b,c,d,e}, will they
  be picked up by 8, or would I have to repartition slightly smaller with
  a useless MBR slice in front?
 
 My $0.02: what about labelling them, say, tunefs -L on UFS partitions,
 and glabel for swap, then change corresponding entry in fstab.  Say:
snip

Yes, I've already done that. However, if gpart doesn't pick up the
underlying ad2d partition glabel won't know to look for a label, so the
entry in /dev/ufs won't show up either.

Ben

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: update to 8.0-RELEASE -- partition gone

[Ben Morrow]

Quoth Marcel Moolenaar xcl...@mac.com:
 On Dec 15, 2009, at 4:08 PM, Ben Morrow wrote:
  Quoth Marcel Moolenaar xcl...@mac.com:
  On Dec 15, 2009, at 2:20 PM, Steven Friedrich wrote:
  
  FreeBSD 8.0 no longer supports dangerously dedicated disks.
  
  This is not true. The problem is that sysinstall creates an invalid
  dangerously dedicated disk, as demonstrated by doing:
snip
  
  Are you able to clarify exactly what is no longer working in 8?
 
 Everything is working, but behaviour has changed for invalid
 disks.

Right. However, if I were to take a system that worked with 7.x and
upgrade, and found that the disks were no longer detected, I would
consider that to be 'not working' :).

 Invalid disks are disks with conflicting partitioning
 information. In FreeBSD 8.x the behaviour is deterministic
 and for the broken dangerously dedicated disks that sysinstall
 creates this means that we use the partition information in
 the BSD disklabel. In FreeBSD 7.x this could come from either
 the MBR or the BSD disklabel, with the MBR the more common
 scenario.

OK, so this is all actually about a bug in sysinstall. It might be nice
if the UPDATING entry mentioned this: as it stands it is not clear this
doesn't affect people who created proper disklabels by hand (including
the obligatory dd to wipe out old MBR labels before starting).

  If I currently have a working ad2{b,c,d,e}, will they
  be picked up by 8, or would I have to repartition slightly smaller with
  a useless MBR slice in front?
 
 Yes, if you have ad2a and not ad2s1a, then you have a
 proper dangerously dedicated disk and FreeBSD 8.x will
 work correctly with your disk.

Thank you for explaining.

Ben

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: update to 8.0-RELEASE -- partition gone

[Daniel O'Connor]

On Wed, 16 Dec 2009, Xin LI wrote:
 My $0.02: what about labelling them, say, tunefs -L on UFS
 partitions, and glabel for swap, then change corresponding entry in
 fstab.  Say:

  - Start into single user
  - tunefs -L root /
  - reboot into single user --- reboot required after tuning /
  - mount -u /; mount -a
  - vi /etc/fstab and change /dev/ad0a to /dev/ufs/root
  - umount -a
  - tunefs -L other partitions
  - mount -a
  - vi /etc/fstab and change the rest
  - reboot

If you use the UFS ID label instead you don't need to reboot because you 
don't modify the superblock :)

You can find the ID with..
line=`dumpfs 2 /dev/null $1 | head | grep superblock\ location`
# dumpfs doesn't print leading 0s
echo $line | sed -nEe 's/superblock location.*id.*\[ (.*)(.*)\ ]/printf %0x 
$((0x\1  32 | 0x\2))/p'

(in an sh like shell)

-- 
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


signature.asc
Description: This is a digitally signed message part.

Problem with kern.icp.shmseg

[Alexander Petrovsky]

Hello!
I have problem with kern.icp.shmseg, when a change value from 128 to 256,
512 in /boot/loader.conf. When system loading the value kern.icp.shmseg
doesn't change.

# cat /boot/loader.conf
# Number of shared memory identifiers
kern.ipc.shmmni=2048
# Number of segments per process #2048
kern.icp.shmseg=256
# Number of semaphore identifiers. 256
kern.ipc.semmni=512
# Maximum number of semaphores in the system. 512
kern.ipc.semmns=1024
# Maximum number of undo structures in the system. 256
kern.ipc.semmnu=512

# Size of TCP control-block hashtable. Default 512
net.inet.tcp.tcbhashsize=4096

# sysctl kern.ipc | grep ipc.s
kern.ipc.semmnu: 512
kern.ipc.semmns: 1024
kern.ipc.semmni: 512
kern.ipc.shmseg: 128
kern.ipc.shmmni: 2048

# uname -a
FreeBSD troll.golodnyj.ru 8.0-STABLE FreeBSD 8.0-STABLE #0 r199880: Thu Dec
3 13:35:21 IRKT 2009
alexan...@troll.golodnyj.ru:/usr/obj/usr/src/sys/WEBKERNEL
i386


-- 
Петровский Александр / Alexander Petrovsky,

ICQ: 350342118
Jabber: ju...@jabber.ru
Phone: +7 914 8 820 815
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: patch: bad ipv6 neighbor solicitation

[Dennis Glatting]

This patch works for me.



On Mon, 14 Dec 2009, Li, Qing wrote:


Please find the more proper fix at

http://people.freebsd.org/~qingli/nd6-patch.diff

I realized I was slightly off in my previous email after
I spent a bit more time looking through the problem.
Both prefixes are present but one was marked off-link due
to the fact only a single prefix route was installed in
the routing table (non RADIX_MPATH system).

I evaluated various options to fixing this issue, however,
due to the association between NDPRF_ONLINK and the route
installation, I decided to go with what I have here for
the time being.

I have verified the fix in my setup. Please apply the
patch and report back.

Thanks,

-- Qing



-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Li, Qing
Sent: Monday, December 14, 2009 3:00 PM
To: Dennis Glatting; JASSAL Aman
Cc: freebsd-...@freebsd.org
Subject: RE: Understanding multiple IPv6 interfaces under 8.0 (fwd)


You don't need to perform all that route-foo. I believe the root cause
of
this issue may be due to a bit of regression in the IPv6 prefix
management
code, and I am in the process of putting together a permanent fix.

The issue as it stands today, is due to how the prefix was inserted in
the first place. Since bce0 was configured first, the interface
associated
with the prefix is bce0. Later the reference count on the prefix is
simply incremented when bce1 configures another IPv6 address of the
same prefix.

When ND6 NS arrives for bce1, due to the interface mismatch of the
prefix
interface against the input interface, the NS packet was considered
invalid and thus dropped.

Again, in case you didn't see my earlier reply, try the temporary hack
at
http://people.freebsd.org/~qingli/nd6-ns.diff

until I commit a permanent patch. The problem was easily reproducible
and
I have verified with limited unit testing the patch works.

-- Qing


-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Dennis Glatting
Sent: Mon 12/14/2009 2:03 PM
To: JASSAL Aman
Cc: freebsd-...@freebsd.org
Subject: Re: Understanding multiple IPv6 interfaces under 8.0 (fwd)


Thanks. Responses in-line.



On Mon, 14 Dec 2009, JASSAL Aman wrote:


Hello Mr.Glatting,

Not that I'm an IPv6 genius, but at first sight your problem seems

to

be a

route-related. I've put comments in-line.


Le Dim 13 d?cembre 2009 22:58, Dennis Glatting a ?crit :



Elmer# netstat -rn
Routing tables


Internet6:
Destination   Gateway

Flags

Netif Expire
::/96 ::1

UGRS

lo0  = default   fd7c:3f2b:e791:1::1
UGSbce0
::1   ::1   UH
lo0 :::0.0.0.0/96 ::1

UGRS

lo0 fd7c:3f2b:e791:1::/64 link#1

U

bce0 fd7c:3f2b:e791:1::ac13:a0alink#1

UHS

lo0 fd7c:3f2b:e791:1:0:1:ac13:a0a link#2

UHS

lo0 fe80::/10 ::1

UGRS

lo0 fe80::%bce0/64link#1

U

bce0 fe80::213:72ff:fe60:ac52%bce0 link#1

UHS

lo0 fe80::%bce1/64link#2

U

bce1 fe80::213:72ff:fe60:ac50%bce1 link#2

UHS

lo0 fe80::%lo0/64 link#3

U

lo0 fe80::1%lo0   link#3

UHS

lo0 ff01:1::/32   fe80::213:72ff:fe60:ac52%bce0

U

bce0 ff01:2::/32

fd7c:3f2b:e791:1:0:1:ac13:a0a

U

bce1 ff01:3::/32   ::1

U

lo0 ff02::/16 ::1

UGRS

lo0 ff02::%bce0/32fe80::213:72ff:fe60:ac52%bce0

U

bce0 ff02::%bce1/32

fd7c:3f2b:e791:1:0:1:ac13:a0a

U

bce1 ff02::%lo0/32 ::1

U

lo0



Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I

was

expecting bce1 rather than lo0, I suppose you were as well :) If I'm

not

mistaken, the packets emanating from bce1 go to the loopback

interface,

thus not really going out. You can try specifying the route manually
with route add *your parameters* or even set it in /etc/rc.conf so
that it's loaded at boot-time. There's no reason why among 2

physical

interfaces sharing the same fabric, one can ship packets out and the
other can't.



I was wondering about the route however I haven't figured out the

trick

to
get what I want. For example:

Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a
delete host fd7c:3f2b:e791:1:0:1:ac13:a0a

Elmer# route add
-inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a/64 -iface bce1
route: writing to routing socket: File exists
add net fd7c:3f2b:e791:1:0:1:ac13:a0a/64: gateway bce1: route already
in table

I did delete the lo0 route before I exected the above command. Also, I
haven't been able to specify a higher metric (e.g., -metric 2). That

is

rejected too. However, I can say:

Elmer# route delete -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a
delete host fd7c:3f2b:e791:1:0:1:ac13:a0a

Elmer# route add -inet6 fd7c:3f2b:e791:1:0:1:ac13:a0a -iface bce1
add 

Re: iSCSI initiator and Dell PowerVault MD3000i

[Daniel Braniss]

 Hi all,
 I am playing with iscsi_initiator on FreeBSD 7-STABLE and Dell 
 PowerVault MD3000i. This is the first time I am testing iSCSI...
 
 Does anyone have FreeBSD's iSCSI initiator in production / heavy load? 
 Or does somebody have experiences with Dell MD3000i?
 
 One thing is poor performance ~ 60 - 70MB/s depending on RAID level 
 used. (poor performance compared to plain SATA disk which have 110MB/s - 
 both tested for reading as it is our planned load - multimedia streaming 
 and downloads)
 
 
 The other thing is some problem with compatibility of initiator and Dell 
 MD3000i.
 
 If I setup RAID 5 'Disk Group' consisted of 4x 1TB SATA drives (in 
 MD3000i) and then created for example 2 'Virtual Disks', both are 
 detected by iscontrol and added to /dev/ as da0 and da1, but da1 spams 
 log with messages like this:
 
 Dec 15 04:00:38 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0
 Dec 15 04:00:38 dust kernel: da0: DELL MD3000i 0735 Fixed Direct 
 Access SCSI-5 device
 Dec 15 04:00:38 dust kernel: da1 at iscsi0 bus 0 target 0 lun 1
 Dec 15 04:00:38 dust kernel: da1: DELL MD3000i 0735 Fixed Direct 
 Access SCSI-5 device
 Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough 
 device found at 0:0:2
 Dec 15 04:00:38 dust iscontrol[48576]: cam_open_btl: no passthrough 
 device found at 0:0:3
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(6)/WRITE(6) not 
 supported, increasing minimum_cmd_size to 10.
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 
 0 0 0 0 1 0
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status 
 Error
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check 
 Condition
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC
 Dec 15 04:00:39 dust kernel: (da1:iscsi0:0:0:1): Unretryable error
 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 c 
 7f df ff 0 0 1 0
 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): CAM Status: SCSI Status 
 Error
 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): SCSI Status: Check 
 Condition
 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): ILLEGAL REQUEST asc:94,1
 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Vendor Specific ASC
 Dec 15 04:00:40 dust kernel: (da1:iscsi0:0:0:1): Unretryable error
 Dec 15 04:00:41 dust kernel: (da1:iscsi0:0:0:1): READ(10). CDB: 28 0 0 0 
 0 0 0 0 1 0
 
 The message repeated many times.
 
 If I created more 'Virtual Disks' (7 for example), 3 of them are 
 producing same errors (da1, da3, da5)
 
 If there is only one 'Virtual Disk', it seems fine... until I configured 
 second path to the virtual disk as I want to try gmultipath or geom_fox 
 (MD3000i is dual controller with 4 NICs), then second session produces 
 same errors.
 
 First path - OK:
 
 Dec 15 22:47:57 dust kernel: da0 at iscsi0 bus 0 target 0 lun 0
 Dec 15 22:47:57 dust kernel: da0: DELL MD3000i 0735 Fixed Direct 
 Access SCSI-5 device
 Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough 
 device found at 0:0:1
 Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough 
 device found at 0:0:2
 Dec 15 22:47:57 dust iscontrol[52226]: cam_open_btl: no passthrough 
 device found at 0:0:3
 
 
 Second path - error:
 
 Dec 15 22:48:04 dust kernel: da1 at iscsi0 bus 0 target 1 lun 0
 Dec 15 22:48:04 dust kernel: da1: DELL MD3000i 0735 Fixed Direct 
 Access SCSI-5 device
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(6)/WRITE(6) not 
 supported, increasing minimum_cmd_size to 10.
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 
 0 0 0 0 1 0
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status 
 Error
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check 
 Condition
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC
 Dec 15 22:48:05 dust kernel: (da1:iscsi0:0:1:0): Unretryable error
 Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough 
 device found at 0:1:1
 Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough 
 device found at 0:1:2
 Dec 15 22:48:05 dust iscontrol[52230]: cam_open_btl: no passthrough 
 device found at 0:1:3
 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): READ(16). CDB: 88 0 0 0 
 0 1 5d 21 1f ff 0 0 0 1 0 0
 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status 
 Error
 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): SCSI Status: Check 
 Condition
 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): ILLEGAL REQUEST asc:94,1
 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Vendor Specific ASC
 Dec 15 22:48:06 dust kernel: (da1:iscsi0:0:1:0): Unretryable error
 Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): READ(10). CDB: 28 0 0 0 
 0 0 0 0 1 0
 Dec 15 22:48:07 dust kernel: (da1:iscsi0:0:1:0): CAM Status: SCSI Status