Re: USB Drive not showing up correctly in 8.1 (works in 7.3)
On 17/01/2011, at 5:59 AM, Steve Randall wrote: On Sun, 16 Jan 2011 11:00:01 -0700 (MST) Warren Block wbl...@wonkity.com wrote: On Sat, 15 Jan 2011, per...@pluto.rain.com wrote: Jerahmy Pocott quaken...@optusnet.com.au wrote: I have a USB Drive that was working fine under 7.3, but since updating to 8.1 no longer has the correct /dev entries. Under 7.3 it was da0s1, in 8.1 there is now only da0 and da0a, which shouldn't exist... da0s1 is MBR, da0a is dangerously dedicated. I would not expect differences between 7 and 8 USB to show that on an existing drive. If the drive was reworked during the 7-to-8 upgrade--maybe with bsdlabel auto--that would be a more likely explanation. The actual explanation is the new geom partitioners introduced in 8.0. The disk has an MBR in block 0 and a forgotten BSD label (dangerously dedicated) in block 1. 8.x sensibly ignores one of them; unfortunately it ignores the MBR, not the unwanted BSD label. The solution is: # dd if=/dev/zero of=/dev/da0 seek=1 count=1 Thank you, this does indeed correct the issue. ___ 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
USB Drive not showing up correctly in 8.1 (works in 7.3)
Hello, I have a USB Drive that was working fine under 7.3, but since updating to 8.1 no longer has the correct /dev entries. Under 7.3 it was da0s1, in 8.1 there is now only da0 and da0a, which shouldn't exist.. # fdisk /dev/da0 shows: *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=121601 heads=255 sectors/track=63 (16065 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 1953520002 (953867 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 768/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Which is correct, and thus should result in a s1 in the dev tree.. # bsdlabel /dev/da0 shows: # /dev/da0: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 1953525152 16unused0 0 c: 19535251680unused0 0 # raw part, don't edit I don't think there should even be a label at that level.. # gpart list shows: Geom name: da0 fwheads: 255 fwsectors: 63 last: 1953525167 first: 0 entries: 8 scheme: BSD Providers: 1. Name: da0a Mediasize: 1000204877824 (932G) Sectorsize: 512 Mode: r0w0e0 rawtype: 0 length: 1000204877824 offset: 8192 type: !0 index: 1 end: 1953525167 start: 16 Consumers: 1. Name: da0 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r0w0e0 The scheme seems to indicate that geom is not reading the fdisk data? The dmesg output for the device is: umass0: MSC Bulk-Only Transfer on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: SAMSUNG HD103UJ Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) There is also an error message during boot, which I'm not sure if it's related but says: usbd_set_config_index: could not read device status: USB_ERR_SHORT_XFER Any ideas on how to correct this problem? Cheers! ___ 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: Sysctl knob(s) to set TCP 'nagle' time-out?
On 24/06/2008, at 2:42 AM, Matthew Dillon wrote: It should be noted that Nagle can cause high latencies even when delayed acks are turned off. Nagle's delay is not timed... in its simplest description it prevents packets from being transmitted for new data coming from userland if the data already in the sockbuf (and presumably already transmitted) has not yet been acknowledged. Assuming that a full data packet can't be constructed in the time it takes for the acknowledgement. If you CAN construct a whole packet in that time then Nagle is either doing a good job or you're sending large amounts of data.. Perhaps nagle a) needs a time out, though I don't really think that would help, or b) uses a dynamic 'in-flight' count where it tries to maintain x packets in-flight and only holds packets up when that value is reached.. The idea being that you get the ack on your first packet at the same time as the host should be getting your second packet.. That way you still get to concatenate lots of small packets being generated in a short space of time, but don't hold up sending data because of the ack latency. It should also be possible to detect if the remote host is using delayed acks and compensate for that? Though I'v not considered it in much detail.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Sysctl knob(s) to set TCP 'nagle' time-out?
Hi, I'm wondering if anything exists to set this.. When you create an INET socket without the 'TCP_NODELAY' flag the network layer does 'naggling' on your transmitted data. Sometimes with hosts that use Delayed_ACK (net.inet.tcp. delayed_ack) it creates a dead-lock where the host will not ACK until it gets another packet and the client will not send another packet until it gets an ACK.. The dead-lock gets broken by a time-out, which I think is around 200ms? But I would like to change that time-out if possible to something lower, yet I can't really see any sysctl knobs that have a name that suggests they do that.. So does anyone know IF this can be tuned and if so by what? Cheers, Jerahmy. (And yes you could solve it by setting the TCP_NODELAY flag on the socket, but not everything has programmed in options to set it and you don't always have access to the source, besides setting a sysctl value would be much simpler than recompiling stuff) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysctl knob(s) to set TCP 'nagle' time-out?
On 23/06/2008, at 6:27 PM, Matthew Dillon wrote: Can it break down and cause excessive lag? Yes, it can. Interactive games almost universally have to disable Nagle because the lag is actually due to the data relay from client 1 - server then relaying the interactive event to client 2. Without an immediate interactive response to client 1 the ack gets delayed and the next event from client 1 hits Nagle and stops dead in the water until the first event reaches client 2 and client 2 reacts to it (then client 2 - server - (abort delayed ack and send) - client 1 (client 1's nagle now allows the second event to be transmitted). That isn't a deadlock, just really poor interactive performance in that particular situation. Yeah, that's what I'm talking about. True, it's not really a dead-lock, but it's terribly slow! The interaction can cause a 200ms delay on a LAN, as can be seen with samba if you disable tcp_nodelay.. In anycase, the usual solution is to disable Nagle rather then mess with delayed acks. What we need is a new Nagle that understands the new reality for interactive connections... something that doesn't break performance in the 'server in the middle' data relaying case. Exactly, there is nothing really wrong with delayed acks.. But with sysctl I CAN disable and mess with the delayed acks, but I can't seem to do anything to Nagle. That's why I was thinking if I could change the Nagle time-out to 0ms it would effectively disable it.. Cheers. J. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysctl knob(s) to set TCP 'nagle' time-out?
On 23/06/2008, at 7:00 PM, David Malone wrote: On Mon, Jun 23, 2008 at 05:25:49PM +1000, Jerahmy Pocott wrote: So does anyone know IF this can be tuned and if so by what? You can tune it with net.inet.tcp.delacktime - it should be is ms. Yeah I saw that one. But that only changes the delayed ack... The default value of 100ms seems fairly reasonable unless you're talking about a LAN.. I guess what I really want to do is disable Nagle in the tcp stack, but since you do that with the sockopts call on a per socket basis I'm guessing there isn't any system wide tunable for it.. Thanks, Jerahmy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DVD-RW doesn't write
On 11/06/2008, at 3:28 AM, Sean C. Farley wrote: had problems with burncd and my DVD drive when burning CD-RW's. When I tried atapicam and cdrecord, it gave me problems. I believe it was using burncd prior to atapicam that caused it because it works now if I do not use burncd first. You could try a reboot and use atapicam first; the DVD drive may be in a funny state. Just a guess. Yes, I'v noticed that too. But using atacontrol to reset the channel that the drive is on seems to return it to a working state. Trying to reset the device doesn't fix it (maybe it locks up the whole channel?). I'v managed to get the drive working with cdrecord, it still reports device errors to the console and seems slower than it should be, but it *does* produce readable dvds, which is the main thing! However growisofs (well mkisofs part) won't write files over 2gb? But I'v seen single archives written to span the whole dvd.. Do you need to use -iso-level 3 or 4 to get this functionality? How well supported is reading from disks created with level 4? (level 4 equates to ISO-9660:1999 or version 2 according to the man page). Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
DVD-RW doesn't write
Hello all, I'v been trying to get this dvd burner to burn, but there seems to be something wrong with the driver for the controller or the drive.. On boot it is detected as: acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDR ATAPI DVD A DH20A4P/9P57 at ata0-master UDMA33 It is connected to: atapci0: Intel ICH6 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 16 at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 The message that the controller found a non-ata66 cable is an error, the cable is most certainly ata66 compatible and I'v switched it out to make sure it wasn't faulty.. The drive is able to mount and read cds/dvds fine, but on trying to use burncd it says: acd0: FAILURE - READ_TRACK_INFO ILLEGAL REQUEST asc=0x24 ascq=0x00 Any further attempts produce the above message with no delay to read from the drive, resetting the ata0 channel makes it check the drive again before producing the message. On loading atapicam module it says: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 So I wasn't able to try cdrecord with it.. I also dropped it back ti PIO4 mode in case there was a DMA issue, but I had the same results in PIO. Any more ideas? J. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
