Re: NFS write corruption on 8.0-RELEASE
On Fri, Feb 12, 2010 at 04:08:55PM -0800, alan bryan wrote: > > > --- On Fri, 2/12/10, Rick Macklem wrote: > > > From: Rick Macklem > > Subject: Re: NFS write corruption on 8.0-RELEASE > > To: "Dmitry Marakasov" > > Cc: freebsd-hack...@freebsd.org, freebsd-stable@freebsd.org, "John Baldwin" > > > > Date: Friday, February 12, 2010, 11:12 AM > > > > > > On Fri, 12 Feb 2010, Dmitry Marakasov wrote: > > > > > > > > I'm planning a massive testing for this weekend, > > including removing > > > soft mount option and trying linux client/server. > > > > > > Btw, I forgot to mention that I'm experiencing other > > NFS problems from > > > time to time, including "death" of a mount (that is, > > all processes that > > > try to access it freeze; this cures itself in some > > time with a message > > > "server is alive again"). Also I've seen another > > strange thing - not > > > only the mount dies but the network is flooded with > > NFS traffic. > > > Last time I've seen it quite a while ago, so I don't > > remember the > > > circumstances and direction of the traffic. > > > > > There are some patches at: > > http://people.freebsd.org/~rmacklem > > that may be relevant if you are using vanilla FreeBSD-8.0. > > (They're all > > now in stable/8, but are post-release of 8.0.) > > > > rick > > > > ___ > > 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" > > > > > This is interesting: > > "I've seen another strange thing - not only the mount dies but the network is > flooded with NFS traffic." You might be able to see NFS flooding with: Write file on client. rm the file during the write on the server. The client now gets IO-errors, but keeps trying forever. Maybe it depends on the mechanism the client application uses to write the file. I never reported because my client is an old 7.0-stable system. I originally noticed it when downloading files with seamonkey on my client and mv it on the server to another partition before it was completely downloaded. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: USB support + Supermicro IPMI KVM = no keyboard
On Tue, Jan 29, 2008 at 01:46:42PM -, Steven Hartland wrote: > - Original Message - > From: "Max Laier" <[EMAIL PROTECTED]> > On Tuesday 29 January 2008, Steven Hartland wrote: > > >>So two questions:- > >>1. Can usb support be disabled from the loader? > >>2. Anyone got any ideas why USB would break the IPMI keyboard? > > > >You could try hint.kbdmux.0.disabled="1" - see kdbmux(4) for details. > > Thanks for the idea Max no go unfortunately, also tried:- > hint.usb.0.disabled=1 > hint.uhci.0.disabled=1 > hint.ohci.0.disabled=1 > hint.ukbd.0.disabled=1 Maybe the keyboard is done via USB and the BIOS sets legacy support for USB keyboards, which is disabled by USB drivers to handle it natively. You have to know that USB controllers can emulate the old 8042 driven keyboards in hardware, but this won't allow using other USB devices at the same time. As long as FreeBSD isn't touching the USB controller the emulation would be kept. You should take a lock into the BIOS setup if you can change USB keyboard legacy support. And you should lock into boot messages if there is a non working USB device found. The USB legacy thing is just an assumption - it could be something completely different as well. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any objections/comments on axing out old ATA stack?
On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote: > I have just sent more information to the PR at > http://www.freebsd.org/cgi/query-pr.cgi?pr=157397 > > The short summary (more info in the PR) is: > > - limiting tags to 31 does not help > > - disabling NCQ appears to help in initial testing, but warrants more > testing > > - error happens during WRITE_FPDMA_QUEUED, > > - File system in question is SU+J UFS2 mounted on /usr, and I can for > instance "rm -rf /usr/obj" or just log into GNOME and try to open a > gnome-terminal to trigger stalls; > > - Linux uses 31 tags (for different reason) and has no drive quirks, but > a controller quirk; > > for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it > might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag > - it gets set by Linux on the SB700 that my computer is using, see > ahci_error_intr() in libahci.h - I am not going to interpret that for > lack of expertise, but it does affect error handling and appears to > ignore a certain condition. > > Why only my Samsung HDD drive triggers this but not the WD drive, I do > not know yet. I have had data corruption with Samsung drive and CAM connected to an onboard intel AHCI. The system was known good running with an older FreeBSD version and was brought back into service for another use case with a fresh installation. Regulary on major filesystem write activity we got random FS corruptions and panics. My assumption was broen NCQ firmware on the drive, but have nothing to proof this assumtion. We switched to old ata driver and lived with this until we replaced the whole machine. Don't know if the machine still exists somewhere. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: ZFS with 32-bit, non-x86 kernel
On Fri, Oct 04, 2019 at 05:05:25PM +0300, Andriy Gapon wrote:
>
> Does anyone use ZFS with a 32-bit kernel, that is also not i386 ?
> If you do, could you please let me know? Along with uname -rmp output.
> Thank you!
[51]wb1# uname -rmp
12.0-RELEASE arm armv7
It is a wandboard qaud with iMX6 and 2G RAM.
I'm using two uSD cards with zroot.
I'm also using the same setup on a raspberry Pi1:
[13]time1# uname -rmp
12.0-RELEASE arm armv6
But 512MB RAM are to low for zroot.
It technically does work, but hoks up the CPU in arc_reclaim_thread when
a scrub runs and since it takes forever it always runs.
last pid: 80786; load averages: 6.56, 5.86, 5.75 up 185+05:51:55 11:10:04
372 threads: 5 running, 349 sleeping, 18 waiting
CPU: 0.1% user, 0.0% nice, 86.9% system, 3.8% interrupt, 9.2% idle
Mem: 4960K Active, 38M Inact, 128M Wired, 259M Free
ARC: 24M Total, 8591K MFU, 8896K MRU, 34K Anon, 251K Header, 6888K Other
2676K Compressed, 74M Uncompressed, 28.31:1 Ratio
Swap:
PID USERNAMEPRI NICE SIZERES STATETIMEWCPU COMMAND
8 root -8- 096K arc_re 1597.2 53.94%
zfskern{arc_reclaim_thread}
10 root155 ki31 0 8192 RUN1765.3 9.26% idle
0 root -8- 0 2064K - 75.7H 2.63%
kernel{dp_sync_taskq}
11 root-80- 0 144K WAIT67.8H 1.88% intr{intc0,28:
bcm_dma0}
20 root -8- 0 8192 mmcreq 39.0H 1.31% mmcsd0: mmc/sd
card
12 root -8- 024K - 27.4H 0.87% geom{g_down}
11 root-60- 0 144K WAIT28.6H 0.74% intr{swi4: clock
(0)}
11 root-88- 0 144K WAIT21.1H 0.66% intr{intc0,70: +}
12 root -8- 024K - 19.3H 0.64% geom{g_up}
[16]time1# zpool status
pool: zroot
state: ONLINE
scan: scrub in progress since Mon Jun 10 03:58:19 2019
34.0G scanned at 3.52K/s, 867M issued at 89/s, 1.77G total
0 repaired, 47.78% done, no estimated completion time
config:
NAME STATE READ WRITE CKSUM
zrootONLINE 0 0 0
mirror-0 ONLINE 0 0 0
diskid/DISK-081Cs2a ONLINE 0 0 0
da0s2a ONLINE 0 0 0
errors: No known data errors
--
B.Walter http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /usr/share/man/man8/MAKEDEV.8
On Wed, Oct 31, 2007 at 09:39:23AM -0500, Matthew D. Fuller wrote: > On Tue, Oct 30, 2007 at 10:23:58AM + I heard the voice of > Alex Zbyslaw, and lo! it spake thus: > > > > Of course, with modern systems where nroff-ing a man page takes > > negligible time and system resources, it could also be argued that > > cat-ed man pages should be a thing of the past :-) > > Quite. I don't completly agree. Many people forget that FreeBSD is used on slow embedded systems as well and I prefer having manpoages there as well. > The slowest machine I currently have running (to get slower, I'd have > to dig in my closet) is my laptop, which is a P54 Pentium 133MHz, with > 32 megs of RAM and a hard drive that runs in PIO mode. It's running a > 2002-vintage RELENG_4, on which the largest manpage is perlfunc(1) (at > 71k). On the first run without the manpage in cache: > > % time sh -c 'man perlfunc > /dev/null' > 6.881u 0.204s 0:07.22 98.0% 173+581k 8+0io 0pf+0w [73]arm9# time sh -c 'man perlfunc > /dev/null' Formatting page, please wait...Done. 76.000u 5.000s 3:21.21 40.8%2269+36014k 35+1io 27pf+0w [74]arm9# time sh -c 'man ls > /dev/null' Formatting page, please wait...Done. 15.000u 1.000s 0:45.48 38.3%3286+30833k 18+1io 1pf+0w This was on an AT91RM9200 based system. It wasn't completely idle, since it is currently routing my DSL connection, but you get the point. > A while, but hardly an eternity. A more typical manpage like ls takes > 3 seconds. On a less ancient machine (but still a few generations > back; Athlon 1.25GHz, few month old RELENG_6), the biggest manpage is > perltoc(1) at 150k. A cold cache run there takes just over 2 seconds. > On my workstation (dual Athlon 1.4, HEAD), I've got > wireshark-filter(4) at a whopping 746k. That takes about 8 seconds. > Second place is gcc at 158k, which takes about 1. > > > So, yes; outside of rather special cases, catpages deserve to enjoy > their retirement at this point 8-} arm based FreeBSD is not that common, but 486 classed systems like Soekris are very commonly used. I wouldn't call it that special. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/share/man/man8/MAKEDEV.8
On Wed, Oct 31, 2007 at 02:30:45PM -0500, Matthew D. Fuller wrote: > On Wed, Oct 31, 2007 at 08:08:31PM +0100 I heard the voice of > Bernd Walter, and lo! it spake thus: > > > > I don't completly agree. > > Many people forget that FreeBSD is used on slow embedded systems as > > well and I prefer having manpoages there as well. > > Oh, I don't argue that there are cases where catpages are still > useful. But I think they're the exception, not the rule. When you're > setting up a tiny system (by whatever the standards of the given day > are) or an appliance, you expect the tradeoffs to be rather different > than on a normal (by said standards) general-purpose computer. My point was against retirement, which was mentioned by Alex. For me and many others slow systems are daily business. For many others modern systems are daily business, but those shouldn't think they are alone. We have already to face many slowdowns over the last years, such as the new rc.d system, which is painly slow on slow systems, but it has a real win, so I never complained against rc.d as such and I can live with it, since my systems rarely reboot. In case of catman retirement I just don't see the win, only the negative and just because many people don't see it doesn't mean it doesn't exist. Why do you expect me any tradeoff when there is nothing to trade? Show me the positives that outweights the negatives and I'm on your side. > Heck, looking at Soekris, everything above the 4501 class is probably > faster than my laptop8-} Yes - but the 4501 is not the slowest system we support. And - many people may be surprised - but the 4501 is extremly power hungry compared to what we can do with ARM. The difference between a 4501 and an at91rm9200 based system is nearly a factor three, so there are valid reasons for such a system. And the at91rm9200 is very compareable in speed when it comes to network traffic, although it seems to be unexpected slow on some other points. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mfi0: I/O error on MegaRAID SAS 9361-4i
System ist running ZFS data pool on 12 disk JBOD using MegaRAID SAS 9361-4i controller. After some time it starts printing the following errors: Oct 16 22:26:46 hostname kernel: mfi0: I/O error, cmd=0xfe0001079c90, status=0x3c, scsi_status=0 Oct 16 22:26:46 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:46 hostname kernel: mfisyspd6: hard error cmd=write 410262844-410263362 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe0001077188, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd5: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe00010780f0, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd6: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe00010778f8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd7: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe000107a048, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd7: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe0001078db0, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd6: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe00010784a8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd5: hard error cmd=write 410267090-410267593 Oct 16 22:26:49 hostname kernel: mfi0: Oct 16 22:26:49 hostname kernel: I/O error, cmd=0xfe0001078750, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd10: hard error cmd=write 362223336-362223832 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe0001076660, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd11: hard error cmd=write 362223336-362223831 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe00010774b8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd10: hard error cmd=write 362223336-362223832 Oct 16 22:26:49 hostname kernel: mfi0: I/O error, cmd=0xfe00010788e8, status=0x3c, scsi_status=0 Oct 16 22:26:49 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:49 hostname kernel: mfisyspd11: hard error cmd=write 362223336-362223831 Oct 16 22:26:59 hostname kernel: mfi0: I/O error, cmd=0xfe0001076f68, status=0x3c, scsi_status=0 Oct 16 22:26:59 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:59 hostname kernel: mfisyspd3: hard error cmd=write 295491976-295492474 Oct 16 22:26:59 hostname kernel: mfi0: I/O error, cmd=0xfe00010797c8, status=0x3c, scsi_status=0 Oct 16 22:26:59 hostname kernel: mfi0: sense error 0, sense_key 0, asc 0, ascq 0 Oct 16 22:26:59 hostname kernel: mfisyspd0: hard error cmd=write 295491977-295492475 [...] continues endless [...] Interruptload in MFI is high and gstat shows disk load, but there is no ZFS progress anymore. I can only log into the machine because / is running on UFS. After switching to mrsas things are different. I got the follogin messages: ses0: da0,pass1: Element descriptor: 'Slot00' ses0: da0,pass1: SAS Device Slot Element: 1 Phys at Slot 0 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe080 ses0: da7,pass8: Element descriptor: 'Slot01' ses0: da7,pass8: SAS Device Slot Element: 1 Phys at Slot 1 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe081 ses0: da1,pass2: Element descriptor: 'Slot02' ses0: da1,pass2: SAS Device Slot Element: 1 Phys at Slot 2 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe082 ses0: da6,pass7: Element descriptor: 'Slot03' ses0: da6,pass7: SAS Device Slot Element: 1 Phys at Slot 3 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe083 ses0: da3,pass4: Element descriptor: 'Slot04' ses0: da3,pass4: SAS Device Slot Element: 1 Phys at Slot 4 ses0: phy 0: SATA device ses0: phy 0: parent 5003048001abe0bf addr 5003048001abe084 ses0: da9,pass10: Element descriptor: 'Slot05' ses0: da9,pass10: S
Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]
On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: > [test_check() between the fork and the wait/sleep prevents the > failure from occurring. Even a small access to the memory at > that stage prevents the failure. Details follow.] Maybe a stupid question, since you might have written it somewhere. What medium do you swap to? I've seen broken firmware on microSD cards doing silent data corruption for some access patterns. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ethernet Switch and MIPS
On Fri, Oct 13, 2006 at 11:31:53AM +1300, Marcos Biscaysaqu wrote: > Hi there. > > We have a very interesting Embebed FreeBSD base system using > Netgraph, BGP, Voip over IP (SER and Asterisk), PF, Remote Desktop Client > (netboot), VLANs, Q-in-Q Vlan, VPN, L2tp, pptp, Xmail, Dhcp server, Wireless > etc.. All the setting and config files are created by a "central management > Platform" (Web Interface and Database) . We have more than 600 of this > devices running different services for 4 years. We would like to release an > open free version of the system and also a commercial one and we would like > to know if you know about some kind of "Ethernet switch" from 8 to 24 ports > able to run Freebsd and also if somebody could give us an opinion or ideas, > we would like to know if this could be an interesting idea to do for the > Freebsd community. Don't know what you mean by "Ethernet switch", but a switch is a switch and not a host. Do you think about doing lan bridging with FreeBSD? That's Ok for a few ports, but with many of them it's better to do in hardware. I've build sn ARM based board with an 820.1q capable switch, which is controlable by FreeBSD, but this is still a switch and a FreeBSD host although they are on a single board. It's a 5 port switch with 1 port to FreeBSD, but it's not a major difference to use switch chips with more ports. And finally you can still use a 08/15 manageable switch and control it from FreeBSD - even if it's in a different place. You really should be more specific what you mean. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atacontrol kernel crash (atausb?)
On Wed, Jan 24, 2007 at 12:54:51PM +0100, Hans Petter Selasky wrote: > On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > > Hello, > > > > * Pietro Cerutti <[EMAIL PROTECTED]> wrote: > > > On 1/15/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > > > Everything works nice with umass. It creates the da0 device node. > > > It just shows up these errors, as it always did... > > > GEOM: new disk da0 > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > > da0: Serial Number > > > da0: 40.000MB/s transfers > > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > > I had these messages with two other devices before, an MP3 player and a > > USB floppy drive. I fixed these errors by adding a quirk to > > /sys/cam/scsi/scsi_da.c. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 > > Instead of having all these quirks, isn't it possible that the SCSI layer can > auto-probe this? No - it is intended to fail on devices not supporting the commands. And the user should know if a drive has not been synced befor unplugging it from power. The SCSI Layer could ask if the device has a cache at least, but I this would likely just relocate the problem. Issuing unsupported commands should be harmless for any sane device, but often bad implemented devices just hang on unknown commands. IIRC umass specification has a way to distinguish reduced command set flash type from generic SCSI devices, by interpreting the subclass. That way umass could safely catch such commands. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with nfs+TCP - Resource temporarily unavailable
On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote: > ## > > > I tried the same with an other nfs server (using dill as nfs server this > time - system description is in my 1st mail, same mount options like / > mnt/files). And guess what? dill rebooted immediate... dd came never > back, gave no output > > dill's dmesg shows me: > > fatal kernel trap: > > trap entry = 0x4 (unaligned access fault) > faulting va= 0xfc0006b6f44d > opcode = 0x28 > register = 0x5 > pc = 0xfc541e08 > ra = 0xfc541df4 > sp = 0xfe000a0f9b70 > usp= 0x11ffea80 > curthread = 0xfc000f91ee10 > pid = 343, comm = nfsd This is absolutely known - TCP/nfs has bugs in realigning packets. Don't use TCP on strong aligned architectures. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with nfs+TCP - Resource temporarily unavailable
On Thu, May 26, 2005 at 12:45:50PM +0200, Sten Spans wrote: > On Thu, 26 May 2005, Bernd Walter wrote: > > >On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote: > >>## > >> > >> > >>I tried the same with an other nfs server (using dill as nfs server this > >>time - system description is in my 1st mail, same mount options like / > >>mnt/files). And guess what? dill rebooted immediate... dd came never > >>back, gave no output > >> > >>dill's dmesg shows me: > >> > >>fatal kernel trap: > >> > >>trap entry = 0x4 (unaligned access fault) > >>faulting va= 0xfc0006b6f44d > >>opcode = 0x28 > >>register = 0x5 > >>pc = 0xfc541e08 > >>ra = 0xfc541df4 > >>sp = 0xfe000a0f9b70 > >>usp= 0x11ffea80 > >>curthread = 0xfc000f91ee10 > >>pid = 343, comm = nfsd > > > >This is absolutely known - TCP/nfs has bugs in realigning packets. > >Don't use TCP on strong aligned architectures. > > Still a pr with a proper backtrace would be nice. > Or does one exist already ? Not that I know. I did know exactly when this happens years ago. The backtrace as such will not help you as the panic happens much later than the cause. IIRC the basic problem was that the realignment code only fixes a single missalignment, while theres a chance for more then one. Verify nfs_realign in nfsserver and nfsclient to get an idea. If you are interested - I've found a (non-working) patch that I wrote for it, but the intention of it should be clear. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with nfs+TCP - Resource temporarily unavailable
On Thu, May 26, 2005 at 02:37:35PM +0200, Sten Spans wrote: > On Thu, 26 May 2005, Bernd Walter wrote: > > >>> > >>>This is absolutely known - TCP/nfs has bugs in realigning packets. > >>>Don't use TCP on strong aligned architectures. > >> > >>Still a pr with a proper backtrace would be nice. > >>Or does one exist already ? > > > >Not that I know. > >I did know exactly when this happens years ago. > >The backtrace as such will not help you as the panic happens much > >later than the cause. > >IIRC the basic problem was that the realignment code only fixes > >a single missalignment, while theres a chance for more then one. > >Verify nfs_realign in nfsserver and nfsclient to get an idea. > >If you are interested - I've found a (non-working) patch that I wrote > >for it, but the intention of it should be clear. > > > > Sure. This is an nfsd specific problem, > Or does nfsclient have issues as well ? The code is the same in client and server - as well as the risk to get packets in that form from network. > I'll get a pr going to make sure that the issue > is documented, and possibly narrowed down enough for > other people to start painting a bikeshed about how > it should be fixed. OK. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is sockstat broken in -stable?
On Tue, Nov 07, 2000 at 09:18:01AM -0800, John Polstra wrote: > On a -stable system from October 31, I'm seeing this from sockstat: > > Userland and kernel are in sync. This is on an Alpha, though I > don't know whether that's significant or not. Is anybody else > seeing this problem? It does not work on 4.1-RELEASE alpha too. Only differences is that there are no '?' printed. I can't speak for current because my world is not in sync. i386 current works. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
