Re: GEOM panic
This fixes it, thanks.
On Thu, 19 Dec 2002 [EMAIL PROTECTED] wrote:
Can you try this patch please ?
Index: geom_mbr.c
===
RCS file: /home/ncvs/src/sys/geom/geom_mbr.c,v
retrieving revision 1.28
diff -u -r1.28 geom_mbr.c
--- geom_mbr.c17 Dec 2002 09:44:10 - 1.28
+++ geom_mbr.c19 Dec 2002 06:22:00 -
@@ -393,6 +397,7 @@
g_mbr_print(1, dp + 1);
if ((dp[0].dp_flag 0x7f) == 0
dp[0].dp_size != 0 dp[0].dp_typ != 0) {
+ g_topology_lock();
g_slice_config(gp, slice, G_SLICE_CONFIG_SET,
(((off_t)dp[0].dp_start) 9ULL) + off,
((off_t)dp[0].dp_size) 9ULL,
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch #3 Re: UMA panic under load
On Tue, Dec 17, 2002 at 05:06:06PM -0500, Brian F. Feldman wrote: Matthew Dillon [EMAIL PROTECTED] wrote: Whoop. Ok, here's a new patch. I think this covers all the cases. I've done some testing and it appears to do the right thing, please look it over (the last patch had type-o's and didn't cover the correct cases). I haven't tested, since I haven't provoked that specific panic on my machines, but that does appear that it would indeed fix both issues. Kris, can you confirm that it makes the machines work properly? I'm testing the committed version on the alpha cluster and my local sparc machine. It should be fairly obvious within a few days if it is working. Kris msg49045/pgp0.pgp Description: PGP signature
Re: sshd and PRNG in FreeBSD 5.0 RC1
On Tue, Dec 17, 2002 at 11:08:28PM +, redjupiter wrote: Hi All, I installed FreeBSD 5.0 RC1 and everything seems to be working just fine. I recompiled the kernel with extra hardware including IPSEC , netgraph, ipfilter and ipfw support. Againseem sto be working just fine and find and configured my hardware. However, SSHD started complaining about PRNG being not seeded. I don't know what that is. What is wrong? Something is wrong with your /dev/random device. Most likely you forgot to include it in your kernel config. Kris msg49046/pgp0.pgp Description: PGP signature
Re: 5.0 Install Troubles
On Wed, Dec 18, 2002 at 05:53:17PM -0600, Ryan Sommers wrote: Yah, there isn't a secure dist. I'm doing a full install now, to see if it hits it. I don't understand why only installing base would work on 4.7 but not on 5.0. I believe it's called 'crypto' not 'secure'. I'm not sure why you ran into this problem..it's not supposed to be mandatory. Kris msg49047/pgp0.pgp Description: PGP signature
UMASS USB bug? (getting the Sony disk-on-key device working).
It took a hellofalong time pulling my hair out trying to figure out
why the Sony disk-on-key I just bought didn't work.
First I added a Quirk entry for the standard 6-byte problem, but it
didn't solve the problem.
Finally, after slogging through an insane amount of debugging (I mean,
it really generates a lot of debugging if you turn it all on!) I came
up with the following patch. It appears that when an error occurs
and the umass device tries to read the sense data that it fails
comparing:
sc-transfer_datalen - sc-transfer_actlen != UGETDW(sc-csw.dCSWDataResidue).
As far as I can sc-transfer_actlen is NEVER updated. It is always 0, so
I don't quite see how the calculation could ever possibly be correct
if DataResidue is what I think it is (a count-down of the number of
unused bytes after a transfer).
Note that my other UMASS device, a compact flash reader, has always
worked fine with just the Quirk entry. I really need a USB expert to
tell me what is going on :-)
With the patch below my Sony diskkey works. Note that the junk at the
end of the patch is debugging. I noticed that the CAM layer thought
the READCAPACITY command succeeded when it didn't, and it was generating
weird sector-size errors due to the malloc'd return buffer containing
garbage. I had to put real values in the buffer to catch the problem
consistently. I don't know why the UMASS layer was returning a
success code to CAM for failed READCAPACITY commands but it took an
hour just to figure that CAM was using garbage in the return buffer.
USB Experts gravitate here! Tell me I'm right or explain to me why I'm
wrong, because this stuff is incredibly complex and I'm having problems
thinking straight at 2:30 a.m. :-)
-Matt
Index: dev/usb/umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.11.2.13
diff -u -r1.11.2.13 umass.c
--- dev/usb/umass.c 21 Nov 2002 21:26:14 - 1.11.2.13
+++ dev/usb/umass.c 19 Dec 2002 10:21:58 -
@@ -1488,6 +1488,7 @@
panic(%s: transferred %d bytes instead of %d bytes\n,
USBDEVNAME(sc-sc_dev),
sc-transfer_actlen, sc-transfer_datalen);
+#if 0
} else if (sc-transfer_datalen - sc-transfer_actlen
!= UGETDW(sc-csw.dCSWDataResidue)) {
DPRINTF(UDMASS_BBB, (%s: actlen=%d != residue=%d\n,
@@ -1497,6 +1498,7 @@
umass_bbb_reset(sc, STATUS_WIRE_FAILED);
return;
+#endif
} else if (sc-csw.bCSWStatus == CSWSTATUS_FAILED) {
DPRINTF(UDMASS_BBB, (%s: Command Failed, res = %d\n,
Index: cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.42.2.29
diff -u -r1.42.2.29 scsi_da.c
--- cam/scsi/scsi_da.c 23 Nov 2002 23:21:42 - 1.42.2.29
+++ cam/scsi/scsi_da.c 19 Dec 2002 10:28:11 -
@@ -250,6 +250,14 @@
},
{
/*
+* Sony Key-Storage media fails in terrible ways without
+* both quirks.
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Sony, Storage Media, *},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
+ },
+ {
+ /*
* Sony DSC cameras (DSC-S30, DSC-S50, DSC-S70)
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, Sony, Sony DSC, *},
@@ -546,8 +554,10 @@
rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcap),
M_TEMP,
- M_WAITOK);
-
+ M_WAITOK|M_ZERO);
+ scsi_ulto4b(313, (void *)rcap-length);
+ scsi_ulto4b(512, (void *)rcap-addr);
+
ccb = cam_periph_getccb(periph, /*priority*/1);
scsi_read_capacity(ccb-csio,
/*retries*/1,
@@ -1185,6 +1195,7 @@
softc-minimum_cmd_size = 10;
else
softc-minimum_cmd_size = 6;
+ printf(QUIRKS %04x MCS %d MATCH %p\n, softc-quirks,
+softc-minimum_cmd_size, match);
/*
* Block our timeout handler while we
@@ -1746,6 +1757,8 @@
dp = softc-params;
dp-secsize = scsi_4btoul(rdcap-length);
dp-sectors = scsi_4btoul(rdcap-addr) + 1;
+ printf(RDCAP SECSIZE %d\n, (int)dp-secsize);
+ printf(RDCAP SECTORS %d\n, (int)dp-sectors);
/*
* Have the controller provide us with a geometry
* for
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
Hey, Matt While you're at it, could you have a look at PR kern/46176 ? =) At least would you tell me if you have the same problem with your device(s) On Thu, 2002-12-19 at 11:32, Matthew Dillon wrote: It took a hellofalong time pulling my hair out trying to figure out why the Sony disk-on-key I just bought didn't work. First I added a Quirk entry for the standard 6-byte problem, but it didn't solve the problem. Finally, after slogging through an insane amount of debugging (I mean, it really generates a lot of debugging if you turn it all on!) I came up with the following patch. It appears that when an error occurs and the umass device tries to read the sense data that it fails comparing: sc-transfer_datalen - sc-transfer_actlen != UGETDW(sc-csw.dCSWDataResidue). As far as I can sc-transfer_actlen is NEVER updated. It is always 0, so I don't quite see how the calculation could ever possibly be correct if DataResidue is what I think it is (a count-down of the number of unused bytes after a transfer). Note that my other UMASS device, a compact flash reader, has always worked fine with just the Quirk entry. I really need a USB expert to tell me what is going on :-) With the patch below my Sony diskkey works. Note that the junk at the end of the patch is debugging. I noticed that the CAM layer thought the READCAPACITY command succeeded when it didn't, and it was generating weird sector-size errors due to the malloc'd return buffer containing garbage. I had to put real values in the buffer to catch the problem consistently. I don't know why the UMASS layer was returning a success code to CAM for failed READCAPACITY commands but it took an hour just to figure that CAM was using garbage in the return buffer. USB Experts gravitate here! Tell me I'm right or explain to me why I'm wrong, because this stuff is incredibly complex and I'm having problems thinking straight at 2:30 a.m. :-) -Matt -- Frode Nordahl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
iir problems on -CURRENT
Hello *, Few minutes ago I tried to install FreeBSD 5.0-CURRENT (kernel 2002.12.19) with Intel SRCU31A RAID Controller (firmware 2.34.00-R030) . After unsuccessful try to do it via 'sysinstall', I tried to install FreeBSD to IDE drive and access Intel RAID Controller. I was unsuccessful too. I got following: iir0: Intel Integrated RAID Controller mem 0xfc8f-0xfc8f3fff irq 18 at device 9.0 on pci3 ... GEOM: new disk ad0 ar: FreeBSD check1 failed ad0: ST32122A/0.39 ATA-2 disk at ata0-master ad0: 2014MB (4124736 sectors), 4092 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 ad0: piomode=4 dmamode=2 udmamode=2 cblid=0 Waiting 15 seconds for SCSI devices to settle GEOM: Configure ad0s1, start 32256 length 2111832576 end 2111864831 GEOM: Add ad0s1 hot[0] start 512 length 276 end 787 GEOM: Configure ad0s1a, start 134217728 length 1977614848 end 2111832575 GEOM: Configure ad0s1b, start 0 length 134217728 end 134217727 GEOM: Configure ad0s1c, start 0 length 2111832576 end 2111832575 (probe6:iir0:0:6:0): error 22 (probe6:iir0:0:6:0): Unretryable Error ... Any ideas ? vd To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
On Thu, Dec 19, 2002 at 02:32:23AM -0800, Matthew Dillon wrote: It took a hellofalong time pulling my hair out trying to figure out why the Sony disk-on-key I just bought didn't work. First I added a Quirk entry for the standard 6-byte problem, but it didn't solve the problem. Finally, after slogging through an insane amount of debugging (I mean, it really generates a lot of debugging if you turn it all on!) I came up with the following patch. It appears that when an error occurs and the umass device tries to read the sense data that it fails comparing: sc-transfer_datalen - sc-transfer_actlen != UGETDW(sc-csw.dCSWDataResidue). As far as I can sc-transfer_actlen is NEVER updated. It is always 0, so I don't quite see how the calculation could ever possibly be correct if DataResidue is what I think it is (a count-down of the number of unused bytes after a transfer). I can't comment on this yet. Note that my other UMASS device, a compact flash reader, has always worked fine with just the Quirk entry. I really need a USB expert to tell me what is going on :-) The problem is that an umass bulk only umass device is allowed to stall the comunication pipe on an invalid command. I got the impression that the umass driver doesn't clear the pipe on errors. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM panic
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Craig Rodrigues writes: Hi, I just did a cvsup and rebuilt my kernel, and now my kernel panics upon bootup. I don't have a serial console, so I wrote down the error messages that I saw: I saw this one in the middle of some GEOM debug statements: ar: FreeBSD check1 failed Can you try this patch please ? Index: geom_mbr.c This patch cured my hang-during-boot problem also. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI Bios complaints and Disk Slices
Tekram DC 390 works under sym(4)... Except 390T which is powered by AMD... Cliff Sarginson: Perhaps you need try to play with disk geometry in fdisk... Try to see what geometry is 1st disk and try set something same on 2nd. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On Tue, 17 Dec 2002, Nate Lawson wrote: On Tue, 17 Dec 2002, Cliff Sarginson wrote: Windows .. fine, I installed Linux .. fine. Then I installed FreeBSD...fine *but* the SCSI BIOS on bootup complains that the disk geometry is all cockeyed, and it looks that way from what it says. It warns any non-DOS O/S may have problems using it. Well I have had no problems, and fdisk makes no complaints. What has happened to upset the SCSI BIOS ? The thing it seems to hate is that it is getting 63 heads reported instead of 64. It is a Tekram 390 U/W controller, with an IBM 18MB U160 disk. There have never been any other complaints about the 1st SCSI disk. Diagnostics show no problems. One thing to check is that you should have 1GB drive support enabled. This needs to be done before installing. See the archives for freebsd-scsi list. I am not familiar with trm(4) so perhaps Oliver can fill in more. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
COMPLIMENT OF THE SEASON.
FROM:JULIUS EZE
SUBJECT:BUSINESS PROPOSAL.
DATE:19TH DECEMBER 2002.
House 34/35
Sanisu Fafuwa Street,
Victoria Island,
Lagos.
RE:TRANSFER OF SIXTY FOUR MILLION DOLLARS ( $64 000 000.00)
Dear Sir
I am an auditor by profession,During the last December, I headed a team that
audited the account of UNITED BANK FOR AFRICA {U B A}.
In the course of this assignment, I discovered an amount of sixty four
million dollars floating funds. This amount of money was traced to have been
lodged into the bank since 1995. This account have been dormant since 1999
as there were no deposits and withdrawals from the account up till now.
After I had gone through the record ,I discovered particulars of the account
and detailed information of the owner..This account belongs to MR. PETER
FLEMING an Oil Marchant, a foreigner from Europe. On further inquiries, I
discovered more details tracing the man 's history and finally ,I found out
that he died since 1998 .My invesatigation revealed that MR. PETER has
nobody to inherit this fund.
The assistance I need from you as a foreigner is to provide a reliable and
honest person who will nominate an existing dollar account where this money
can be transferred to gradually. All necessary documents relating to this
deposit are now in my care and no body will fault this transfer if needed
information are provided by a foregner since news of PETERS' death is not to
the bank. I need your full understanding and co-operation to make this work
well because the management of the bank ,is ready to approve this payment to
any foreigner, who has correct information of this account .Which I will
equip you with, upon your positive responce .Two of us will meet in your
country at least two days ahead of the money being credited to your account.
I will use my position and influence ,to obtain all legal approvals , for
onward transfer of this money to your account ,with appropriate clearance
from the relevant ministries and foreign exchange department without
question. For a test ,we shall start by transfering TWENTY FOUR MILLION
DOLLARS after I have my due share, we arrange for subsequent transfer. You
will be entitled to 35% of any segment of the transfer while I take 60% then
the remaining 5% will be for expenses both parties might incure in the
process. For utmost confident ,our first communication will be restricted to
this e-mail only , but include your private and confidential phone and fax
number,in your return mail.Please if you are finding it defficult to reach
me,you can as well contact me on this email bus:[EMAIL PROTECTED] .
Yours Truly,
JULIUS EZE.
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SCSI Bios complaints and Disk Slices
On Tue, Dec 17, 2002 at 10:59:37AM -0800, Nate Lawson wrote: On Tue, 17 Dec 2002, Cliff Sarginson wrote: Windows .. fine, I installed Linux .. fine. Then I installed FreeBSD...fine *but* the SCSI BIOS on bootup complains that the disk geometry is all cockeyed, and it looks that way from what it says. It warns any non-DOS O/S may have problems using it. Well I have had no problems, and fdisk makes no complaints. What has happened to upset the SCSI BIOS ? The thing it seems to hate is that it is getting 63 heads reported instead of 64. It is a Tekram 390 U/W controller, with an IBM 18MB U160 disk. There have never been any other complaints about the 1st SCSI disk. Diagnostics show no problems. One thing to check is that you should have 1GB drive support enabled. This needs to be done before installing. See the archives for freebsd-scsi list. I am not familiar with trm(4) so perhaps Oliver can fill in more. Yes, that is going to be a lot of work :( What is strange is that it is only the SCSI BIOS on the Tekram board that is complaining. Everything seems to be working fine. And I have never had complaints about the first SCSI disk, which is my main FreeBSD Stable system in constant use ! Well, I will have to think on how I am going to do this, it will I guess also affect the SCSI BIOS view of the first disk as well. Mmm. What Sherlock Holmes would call a 2 pipe problem. Thanks for the answer. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 Install Troubles
To see if it was related to installing in a vmware vm I whipped out the laptop last night and ran an install. Sure enough I ran into the same problem on the laptop when trying to install only base + linux compatability. When it gets to installing linux compatability it complains about libssl not being installed. So, is this a 5.0 bug? I'm running an install of minimal right now to see if that works. I really don't like having to install a whole bunch of documentation that I already have in a number of other boxes, anyone know why libssl isn't in base? Ryan On Thu, 2002-12-19 at 04:29, Kris Kennaway wrote: On Wed, Dec 18, 2002 at 05:53:17PM -0600, Ryan Sommers wrote: Yah, there isn't a secure dist. I'm doing a full install now, to see if it hits it. I don't understand why only installing base would work on 4.7 but not on 5.0. I believe it's called 'crypto' not 'secure'. I'm not sure why you ran into this problem..it's not supposed to be mandatory. Kris -- Ryan leadZERO Sommers [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM panic
On Thu, Dec 19, 2002 at 07:22:45AM +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Craig Rodrigues writes: Hi, I just did a cvsup and rebuilt my kernel, and now my kernel panics upon bootup. I don't have a serial console, so I wrote down the error messages that I saw: I saw this one in the middle of some GEOM debug statements: ar: FreeBSD check1 failed Can you try this patch please ? That patch worked, and I no longer get a kernel panic. Do you know what the ar: FreeBSD check1 failed error message is caused by? I am attaching the GEOM dmesg messages. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] ad0: success setting PIO4 on Acer chip GEOM: new disk ad0 ar: FreeBSD check1 failed ad0: IC35L060AVER07-0/ER6OA44A ATA-5 disk at ata0-master ad0: 32253MB (66055248 sectors), 65531 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, PIO4 ad0: piomode=4 dmamode=2 udmamode=5 cblid=1 Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. sym0: enabling clock multiplier sym0: Downloading SCSI SCRIPTS. GEOM: Configure ad0s1, start 32256 length 7339885056 end 7339917311 GEOM: Configure ad0s2, start 7339917312 length 6291210240 end 13631127551 GEOM: Add ad0s1 hot[0] start 512 length 276 end 787 GEOM: Configure ad0s1a, start 0 length 209715200 end 209715199 GEOM: Configure ad0s1b, start 209715200 length 524288000 end 734003199 GEOM: Configure ad0s1c, start 0 length 7339885056 end 7339885055 GEOM: Configure ad0s1e, start 734003200 length 52428800 end 786431999 GEOM: Configure ad0s1f, start 786432000 length 6553453056 end 7339885055 GEOM: Add ad0s2 hot[0] start 512 length 276 end 787 GEOM: Configure ad0s2a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s2c, start 0 length 6291210240 end 6291210239 GEOM: Configure ad0s2e, start 134217728 length 268435456 end 402653183 GEOM: Configure ad0s2f, start 402653184 length 268435456 end 671088639 GEOM: Configure ad0s2g, start 671088640 length 5620121600 end 6291210239 (probe5:sym0:0:5:0): error 22 (probe5:sym0:0:5:0): Unretryable Error (probe0:sym0:0:0:0): Retrying Command (probe1:sym0:0:1:0): Retrying Command (probe2:sym0:0:2:0): Retrying Command pass0 at sym0 bus 0 target 0 lun 0 pass0: SEAGATE ST5660N 0592 Fixed Direct Access SCSI-2 device pass0: Serial Number DP651202 pass0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass1 at sym0 bus 0 target 1 lun 0 pass1: IBM DORS-32160 WA0A Fixed Direct Access SCSI-2 device pass1: Serial Number 5U2V3566 pass1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass2 at sym0 bus 0 target 2 lun 0 pass2: IBM DDRS-34560D DC1B Fixed Direct Access SCSI-2 device pass2: Serial Number QD740138 pass2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled pass3 at sym0 bus 0 target 5 lun 0 pass3: SONY CD-ROM CDU-76S 1.1c Removable CD-ROM SCSI-2 device pass3: 5.681MB/s transfers (5.681MHz, offset 15) GEOM: new disk da0 da0 at sym0 bus 0 target 0 lun 0 da0: SEAGATE ST5660N 0592 Fixed Direct Access SCSI-2 device da0: Serial Number DP651202 da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 520MB (1065664 512 byte sectors: 64H 32S/T 520C) GEOM: new disk da1 GEOM: new disk da2 (cd0:sym0:0:5:0): Retrying Command cd0 at sym0 bus 0 target 5 lun 0 cd0: SONY CD-ROM CDU-76S 1.1c Removable CD-ROM SCSI-2 device cd0: 5.681MB/s transfers (5.681MHz, offset 15) cd0: cd present [273047 x 2048 byte records] GEOM: Configure da0s1, start 31744 length 1047552 end 1079295 GEOM: Configure da0s2, start 1079296 length 21046272 end 22125567 GEOM: Configure da0s3, start 22125568 length 523458560 end 545584127 da1 at sym0 bus 0 target 1 lun 0 da1: IBM DORS-32160 WA0A Fixed Direct Access SCSI-2 device da1: Serial Number 5U2V3566 da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da2 at sym0 bus 0 target 2 lun 0 da2: IBM DDRS-34560D DC1B Fixed Direct Access SCSI-2 device da2: Serial Number QD740138 da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) GEOM: Configure da1s1, start 31744 length 2095104 end 2126847 GEOM: Configure da1s2, start 2126848 length 2160877568 end 2163004415 GEOM: Configure da2s1, start 31744 length 4565390336 end 4565422079 MBREXT Slice 5 on da0s3: 80 01 01 29 06 10 3e 9d 3e 00 00 00 78 e1 01 00 |...)..x...| [0] f:80 typ:6 s(CHS):41/1/1 e(CHS):157/16/62 s:62 l:123256 00 00 01 9e 05 10 fe f2 b6 e1 01 00 f6 b7 0d 00 || [1] f:00 typ:5 s(CHS):158/0/1 e(CHS):242/16/254 s:123318 l:899062 GEOM: Configure da0s5, start 31744 length 63107072 end 63138815 MBREXT Slice 6 on da0s3: 00 01 01 9e 07 10 fe f2 3e 00 00 00 b8 b7 0d 00 |...| [0] f:00 typ:7 s(CHS):158/1/1 e(CHS):242/16/254 s:62 l:899000 00 00 00 00
Re: SCSI Bios complaints and Disk Slices
On Thu, Dec 19, 2002 at 07:56:02PM +0600, Maxim M. Kazachek wrote: Tekram DC 390 works under sym(4)... Except 390T which is powered by AMD... Cliff Sarginson: Perhaps you need try to play with disk geometry in fdisk... Try to see what geometry is 1st disk and try set something same on 2nd. Actually, FreeBSD reports the correct geometry in the startup messages, but fdisk gives the insane geometry the SCSI BIOS complains about. So with due precaution I set the geometry in fdisk to what it should be and it is, or appears to all be fine. I think the 1GB option in the controller is not actually relevant, it has to do with the old 1GB--8GB limitations I think. Mmm. Well it *looks* like it should now. -- Regards Cliff Sarginson The Netherlands [ This mail has been checked as virus-free ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM panic
In message [EMAIL PROTECTED], Craig Rodrigues writes: Do you know what the ar: FreeBSD check1 failed error message is caused by? I think it is the ata-raid driver mumbling under its breath when it doesn't find anything for it to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
On Thu, Dec 19, 2002 at 12:08:27PM +0100, Frode Nordahl wrote: Hey, Matt While you're at it, could you have a look at PR kern/46176 ? =) At least would you tell me if you have the same problem with your device(s) The umass cam interaction is questionable. I've seen lots of problems caused by this. As I have problems with my device caused by this too I already placed it on my todo list. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patch #3 Re: swapoff code comitted.
Thus spake Matthew Dillon [EMAIL PROTECTED]: :Looks good to me, modulo a few nits. I try not to nitpick, but :I've mentioned a few of them below. (BDE does a better job of it :than I do anyway. :-) : :The patch puts identical functionality in two places, so maybe it :would make sense to rip support for -s out of pstat/swapinfo (and :integrate 'pstat -ss' support into swapctl). If we really want to :go the NetBSD way, we could even integrate the swapon(2) and :swapoff(2) into swapctl(2). Doesn't matter to me. I think we should keep swapon and swapoff as separate commands. They are the most intuitive of the lot. NetBSD's pstat supports -s, as does OpenBSD's, so there is no reason to rip out support for -s in our pstat. Neither OpenBSD or NetBSD have swapinfo that I can find. We could potentially rip out the swapinfo command though all it is is a hardlink to pstat so it wouldn't really save us anything. I guess I'm just bothered by the fact that it's duplicating functionality. (In particular, the part that is duplicated was working fine in pstat and doesn't need to be on the root filesystem.) But when it comes down to it, I don't have a problem as long as other people are maintaining it. : + if (strstr(argv[0], swapon)) : + which_prog = SWAPON; : + else if (strstr(argv[0], swapoff)) : + which_prog = SWAPOFF; : :It's probably better to do a strcmp on strrchr(argv[0], '/') when :argv[0] contains a slash. Otherwise people will wonder why :swapoff(8) breaks when they (perhaps mistakenly) compile and run :it from the src/sbin/swapon directory. Hmm. How about a strstr on a strrchr. I don't like making exact comparisons because it removes flexibility that someone might want in regards to hardlinks (for example, someone might want to add a version or other suffix to differentiate certain binaries in a test environment or in an emulation environment). e.g. bsdswapon vs swapon. Isn't there a shortcut procedure to handle the NULL return case? I know there is one for a forward scan. I thought there was one for the reverse scan too. if ((ptr = strrchr(argv[0], '/')) == NULL) ptr = argv[0]; if (strstr(ptr, swapon)) ... Sounds fine. I don't know of a more concise approach offhand, and the original version used essentially what you just wrote. (I used strcmp(), so ptr had to be incremented to skip the slash.) :The repeated 'whichprog == foo' tests can be combined into a :single test at the end of the loop. They do subtly different things so I am not sure what you mean. You need to provide some code here. Yow, I didn't realize that -a and -d mean completely different things in swalctl vs swapon/swapoff. If that's how it has to work for compatibility, then it looks okay to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic: memory modified after free
Hi,
Running 5.0-RC as of yesterday on i386. background fsck was in progress,
but other than that system was idle. Logged in as root on the console, had
cd'd to a ports directory. (note that it panics almost instantly when
using the console, but lasts upto 10 minutes when in use over ssh)
Running make deinstall triggered this panic:
Memory modified after free 0xc1891c00(1020)
panic: Most recently used by none
#10 0xc0204cfb in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc032c7dd in mtrash_ctor (mem=0xc1891c00, size=0, arg=0x0)
at /usr/src/sys/vm/uma_dbg.c:138
#12 0xc032b1e7 in uma_zalloc_arg (zone=0xc0b653c0, udata=0x0, flags=0)
at /usr/src/sys/vm/uma_core.c:1358
#13 0xc01f95ad in malloc (size=6, type=0xc03cfb00, flags=0)
at /usr/src/sys/kern/kern_malloc.c:182
#14 0xc01df80c in exec_elf32_imgact (imgp=0xd0e18b88) at imgact_elf.c:804
#15 0xc01ec952 in kern_execve (td=0xc1924620, fname=---Can't read userspace from dump,
or kernel process---)
at /usr/src/sys/kern/kern_exec.c:313
#16 0xc01ed430 in execve (td=0x0, uap=0x0) at /usr/src/sys/kern/kern_exec.c:698
#17 0xc035f90e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135232232, tf_esi =
135232268, tf_ebp = -1077937688, tf_isp = -790524556, tf_ebx = 0, tf_edx =
135232268, tf_ecx = 135232303, tf_eax = 59, tf_trapno = 12, tf_err = 2,
tf_eip = 134723319, tf_cs = 31, tf_eflags = 642, tf_esp = -1077937716,
tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#18 0xc034faad in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
The machine seems perfectly stable in single user mode. It also seems
pretty stable at the moment with linux emulation, usbd, sendmail, ipv6,
nfs server and moused enables commented out of rc.conf. I will try to add
one at a time tonight to determine which is at fault.
Gavin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
: :On Thu, Dec 19, 2002 at 12:08:27PM +0100, Frode Nordahl wrote: : Hey, Matt : : While you're at it, could you have a look at PR kern/46176 ? =) : : At least would you tell me if you have the same problem with your : device(s) : :The umass cam interaction is questionable. :I've seen lots of problems caused by this. :As I have problems with my device caused by this too I already placed it on :my todo list. : :-- :B.Walter COSMO-Project http://www.cosmo-project.de :[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] The panic described in 46176 has happened to me on -current. On -stable I have managed (very easily) to get the CAM layer vs UMASS layer into a confused state where the CAM layer thinks it is still attached but the UMASS layer thinks it has detached / cleaned everything out. In both cases it appears that memory is being freed by one side which is still being used by the other side but I haven't tracked down the exact cause. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
: : Note that my other UMASS device, a compact flash reader, has always : worked fine with just the Quirk entry. I really need a USB expert to : tell me what is going on :-) : :The problem is that an umass bulk only umass device is allowed to stall the :comunication pipe on an invalid command. :I got the impression that the umass driver doesn't clear the pipe on :errors. : :-- :B.Walter COSMO-Project http://www.cosmo-project.de In my traces I did occassionally see a command wind up in a STALLED state, but most of the time it either wound up in a BABBLE state or in a NAK state and hit the 5 second timeout. Since I removed the conditional (the #if 0 in the patch I posted earlier), I have not seen either state. These problems always occured while the CAM layer was probing the device (e.g. doing a READ CAPACITY, telling the lower layer to not allow user removal (as if that helps)). Once the CAM layer was actually able to get past that state the actual READs and WRITEs worked fine with just the Quirk entry, before my #if 0 patch. Prior to the patch it took a lot of random pulling of the device, putting it back in, pulling it again, putting it back in, camcontrol reset 1, camcontrol rescan 1, that sort of thing, before I would either get the device to work or the system would panic :-). After the patch everything works fine (though I'm sure pulling the device without unmounting it first will still lead to problems similar to those describde by Frode). p.s. the patch was against -stable. -current was crashing on me too much while playing with the disk key, but I'm sure it applies to -current too. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: UMASS USB bug? (getting the Sony disk-on-key device working)
On 19-Dec-2002 Matthew Dillon wrote: It took a hellofalong time pulling my hair out trying to figure out why the Sony disk-on-key I just bought didn't work. First I added a Quirk entry for the standard 6-byte problem, but it didn't solve the problem. You don't need the 6-byte quirk entries anymore. The umass(4) driver automatically handles 6-byte commands (converting them to 10-byte commands) and has done so for a while now. You should at least try removing the 6 byte quirk for now. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote: : :On Thu, Dec 19, 2002 at 12:08:27PM +0100, Frode Nordahl wrote: : Hey, Matt : : While you're at it, could you have a look at PR kern/46176 ? =) : : At least would you tell me if you have the same problem with your : device(s) : :The umass cam interaction is questionable. :I've seen lots of problems caused by this. :As I have problems with my device caused by this too I already placed it on :my todo list. The panic described in 46176 has happened to me on -current. On -stable I have managed (very easily) to get the CAM layer vs UMASS layer into a confused state where the CAM layer thinks it is still attached but the UMASS layer thinks it has detached / cleaned everything out. In both cases it appears that memory is being freed by one side which is still being used by the other side but I haven't tracked down the exact cause. The umass driver uses a single sim for all umass devices. There are a lot of workarounds and bugs introduced because of this. Also there is a small static limit (IIRC 3) in the number of instances supported. You could see a difference in behavour, if you have another umass device connected. I wouldn't be surprised if this problem belongs here too. My guess would be because umass disconnects the sim on the last instance but tells cam to rescan the pseudo bus. My intention is to rewrite the parts of umass to use multiple sims so LUNs and many instances actually work and hopefully a lot of other problems like this can be solved too. BTW: I've seen such disconnect/reconnect problems with -stable too, but without a panic. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On Thu, Dec 19, 2002 at 12:24:09PM -0500, John Baldwin wrote: On 19-Dec-2002 Matthew Dillon wrote: It took a hellofalong time pulling my hair out trying to figure out why the Sony disk-on-key I just bought didn't work. First I added a Quirk entry for the standard 6-byte problem, but it didn't solve the problem. You don't need the 6-byte quirk entries anymore. The umass(4) driver automatically handles 6-byte commands (converting them to 10-byte commands) and has done so for a while now. You should at least try removing the 6 byte quirk for now. I tought this too and it's true for many devices, but the umass device gets an invalid command first and the umass driver is required to handle that failure in a special way for some devices. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
: didn't solve the problem. : : You don't need the 6-byte quirk entries anymore. The umass(4) driver : automatically handles 6-byte commands (converting them to 10-byte commands) : and has done so for a while now. You should at least try removing the : 6 byte quirk for now. : :I tought this too and it's true for many devices, but the umass device :gets an invalid command first and the umass driver is required to :handle that failure in a special way for some devices. : :-- :B.Walter COSMO-Project http://www.cosmo-project.de :[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] I'll try to get the diskkey working on -current first (I now have it working on -stable), then I'll try removing the Quirk entry on both stable and current to see if it still works and post a followup. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On 19-Dec-2002 Bernd Walter wrote: On Thu, Dec 19, 2002 at 12:24:09PM -0500, John Baldwin wrote: On 19-Dec-2002 Matthew Dillon wrote: It took a hellofalong time pulling my hair out trying to figure out why the Sony disk-on-key I just bought didn't work. First I added a Quirk entry for the standard 6-byte problem, but it didn't solve the problem. You don't need the 6-byte quirk entries anymore. The umass(4) driver automatically handles 6-byte commands (converting them to 10-byte commands) and has done so for a while now. You should at least try removing the 6 byte quirk for now. I tought this too and it's true for many devices, but the umass device gets an invalid command first and the umass driver is required to handle that failure in a special way for some devices. Eh? For ATAPI and UFM devices we never send a 6 byte command to the device that can fail, only 10 byte commands. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On Thu, Dec 19, 2002 at 12:49:16PM -0500, John Baldwin wrote: On 19-Dec-2002 Bernd Walter wrote: On Thu, Dec 19, 2002 at 12:24:09PM -0500, John Baldwin wrote: On 19-Dec-2002 Matthew Dillon wrote: It took a hellofalong time pulling my hair out trying to figure out why the Sony disk-on-key I just bought didn't work. First I added a Quirk entry for the standard 6-byte problem, but it didn't solve the problem. You don't need the 6-byte quirk entries anymore. The umass(4) driver automatically handles 6-byte commands (converting them to 10-byte commands) and has done so for a while now. You should at least try removing the 6 byte quirk for now. I tought this too and it's true for many devices, but the umass device gets an invalid command first and the umass driver is required to handle that failure in a special way for some devices. Eh? For ATAPI and UFM devices we never send a 6 byte command to the device that can fail, only 10 byte commands. I believed this was a SCSI over bulk only device. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [src] cvs commit: src/sys/geom geom_dev.c
This commit is crashing my -current box on boot when it goes to check for a core. I get the panic: Negative bio_offset (-1024) on bio ... Userland probably should not be allowed to panic the box in that way. -Matt Matthew Dillon [EMAIL PROTECTED] : :phk 2002/12/13 14:04:45 PST : : Modified files: :sys/geom geom_dev.c : Log: : Add a couple of KASSERTS, just in case. : : Revision ChangesPath : 1.33 +4 -0 src/sys/geom/geom_dev.c : : :Index: src/sys/geom/geom_dev.c :diff -u src/sys/geom/geom_dev.c:1.32 src/sys/geom/geom_dev.c:1.33 :--- src/sys/geom/geom_dev.c:1.32 Fri Nov 1 07:56:26 2002 :+++ src/sys/geom/geom_dev.cFri Dec 13 14:04:45 2002 :@@ -32,7 +32,7 @@ : * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF : * SUCH DAMAGE. : * :- * $FreeBSD: /repoman/r/ncvs/src/sys/geom/geom_dev.c,v 1.32 2002/11/01 15:56:26 phk :Exp $ :+ * $FreeBSD: /repoman/r/ncvs/src/sys/geom/geom_dev.c,v 1.33 2002/12/13 22:04:45 phk :Exp $ : */ : : #include sys/param.h :@@ -388,7 +388,11 @@ : gp = dev-si_drv1; : cp = dev-si_drv2; : bp2 = g_clone_bio(bp); :+ KASSERT(bp2 != NULL, (XXX: ENOMEM in a bad place)); : bp2-bio_offset = (off_t)bp-bio_blkno DEV_BSHIFT; :+ KASSERT(bp2-bio_offset = 0, :+ (Negative bio_offset (%jd) on bio %p, :+ (intmax_t)bp2-bio_offset, bp)); : bp2-bio_length = (off_t)bp-bio_bcount; : bp2-bio_done = g_dev_done; : g_trace(G_T_BIO, : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [src] cvs commit: src/sys/geom geom_dev.c
In message [EMAIL PROTECTED], Matthew Dillon w rites: This commit is crashing my -current box on boot when it goes to check for a core. I get the panic: Negative bio_offset (-1024) on bio ... Userland probably should not be allowed to panic the box in that way. Backtrace ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
: : Eh? For ATAPI and UFM devices we never send a 6 byte command to the : device that can fail, only 10 byte commands. : :I believed this was a SCSI over bulk only device. : :-- :B.Walter COSMO-Project http://www.cosmo-project.de :[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] Yes, this is a USB DiskKey - UMASS storage, SCSI over bulk only device. I've done some further testing on both -current and -stable. I cannot get the device to work unless I have the quirk entry in scsi_da.c. -Current has a quirk table for umass.c and already has a flag which disables the residue test. The patch for current thus does not require #if 0'ing out that code, only a quirk entry. Since I don't need any hacks beyond what is there already I am going to commit the two quirk entries for -current now. However, I am still unable to get the device to work properly in -Current. This is what happens (see below). test2 kernel: umass0: Sony USB Storage Media, rev 1.10/2.00, addr 2 test2 kernel: umass0: Get Max Lun not supported (IOERROR) test2 kernel: da2 at umass-sim0 bus 0 target 0 lun 0 test2 kernel: da2: Sony Storage Media 2.51 Removable Direct Access SCSI-0 device test2 kernel: da2: 1.000MB/s transfers test2 kernel: da2: Attempt to query device size failed: UNIT ATTENTION, Medium not present test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 test2 kernel: (da2:umass-sim0:0:0:0): Medium not present test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 test2 kernel: (da2:umass-sim0:0:0:0): Medium not present test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 test2 kernel: (da2:umass-sim0:0:0:0): Medium not present test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 test2 kernel: (da2:umass-sim0:0:0:0): Medium not present test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 test2 kernel: (da2:umass-sim0:0:0:0): Medium not present test2 kernel: (da2:umass-sim0:0:0:0): Retries Exhausted test2 kernel: Opened disk da2 - 6 But then I get this: test2 kernel: (da2:umass-sim0:0:0:0): Not ready to ready change, medium may have changed test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) (no retry occurs) And if I tell cam to rescan a different Lun it works: camcontrol rescan 2:0:1 da3 at umass-sim0 bus 0 target 0 lun 1 da3: Sony Storage Media 2.51 Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: 125MB (256352 512 byte sectors: 64H 32S/T 125C) camcontrol rescan 2:0:2 da3 at umass-sim0 bus 0 target 0 lun 1 da3: Sony Storage Media 2.51 Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: 125MB (256352 512 byte sectors: 64H 32S/T 125C) I am not sure what is going on but I think in -current CAM is exhausting its retries too quickly (the messages are instantanious) and not giving the device enough time to boot up. This is because, I believe, the usb controller is now a kerneland thread instead of a userland usbd and is responding instantly to the device presence. I would have expected 'camcontrol rescan 2:0:0' but it doesn't. It just says: # camcontrol rescan 2:0:0 Re-scan of 2:0:0 was successful But then doesn't do anything. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [src] cvs commit: src/sys/geom geom_dev.c
: :In message [EMAIL PROTECTED], Matthew Dillon w :rites: :This commit is crashing my -current box on boot when it :goes to check for a core. I get the panic: : :Negative bio_offset (-1024) on bio ... : :Userland probably should not be allowed to panic the box :in that way. : :Backtrace ? : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 userland read() system call from savecore running through the standard sequence to read from a physical device, then panicing in geom. I don't have the serial console connected to that machine but I'll try to reproduce it in a little while and manually transcribe the backtrace. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Dec 19 09:37:06 PST 2002 -- Kernel build for GENERIC completed on Thu Dec 19 10:28:44 PST 2002 -- Kernel build for LINT started on Thu Dec 19 10:28:44 PST 2002 -- === vesa Makefile, line 5401: warning: duplicate script for target geom_bsd.o ignored Makefile, line 5404: warning: duplicate script for target geom_mbr.o ignored /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:778: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget': /local0/scratch/des/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 2 of `bcopy' discards qualifiers from pointer target type
Re: [src] cvs commit: src/sys/geom geom_dev.c
In message [EMAIL PROTECTED], Matthew Dillon w rites: : :In message [EMAIL PROTECTED], Matthew Dillon w :rites: :This commit is crashing my -current box on boot when it :goes to check for a core. I get the panic: : :Negative bio_offset (-1024) on bio ... : :Userland probably should not be allowed to panic the box :in that way. : :Backtrace ? : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 userland read() system call from savecore running through the standard sequence to read from a physical device, then panicing in geom. I don't have the serial console connected to that machine but I'll try to reproduce it in a little while and manually transcribe the backtrace. Why would savecore seek to a negative index ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UMASS USB again...
It took a hellofalong time pulling my hair out trying to figure out why the
Fumerola disk-on-key I just bought didn't work.
First I added a Quirk entry for the standard 6-byte problem, but it didn't solve
the problem.
Finally, after slogging through an insane amount of debugging (I mean, it really
generates a lot of debugging if you turn it all on!) I came up with the following
patch. It appears that when an error occurs and the umass device tries to read the
sense data that it fails comparing:
sc-transfer_datalen - sc-transfer_actlen != UGETDW(sc-csw.dCSWDataResidue).
As far as I can sc-transfer_actlen is NEVER updated. It is always 0, so I don't
quite see how the calculation could ever possibly be correct if DataResidue is what I
think it is (a count-down of the number of unused bytes after a transfer).
Note that my other UMASS device, a compact flash reader, has always worked fine
with just the Quirk entry. I really need a USB expert to tell me what is going on :-)
With the patch below my Sony diskkey works. Note that the junk at the end of the
patch is debugging. I noticed that the CAM layer thought the READCAPACITY command
succeeded when it didn't, and it was generating weird sector-size errors due to the
malloc'd return buffer containing garbage. I had to put real values in the buffer to
catch the problem consistently. I don't know why the UMASS layer was returning a
success code to CAM for failed READCAPACITY commands but it took an hour just to
figure that CAM was using garbage in the return buffer.
USB Experts gravitate here! Tell me I'm right or explain to me why I'm wrong,
because this stuff is incredibly complex and I'm having problems thinking straight at
2:30 a.m. :-)
-Matt
Index: dev/usb/umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.11.2.13
diff -u -r1.11.2.13 umass.c
--- dev/usb/umass.c 21 Nov 2002 21:26:14 - 1.11.2.13
+++ dev/usb/umass.c 19 Dec 2002 10:21:58 -
@@ -1488,6 +1488,7 @@
panic(%s: transferred %d bytes instead of %d bytes\n,
USBDEVNAME(sc-sc_dev),
sc-transfer_actlen, sc-transfer_datalen);
+#if 0
} else if (sc-transfer_datalen - sc-transfer_actlen
!= UGETDW(sc-csw.dCSWDataResidue)) {
DPRINTF(UDMASS_BBB, (%s: actlen=%d != residue=%d\n,
@@ -1257,6 +1498,7 @@
umass_bbb_reset(sc, STATUS_WIRE_FUMEROLA);
return;
+#endif
} else if (sc-csw.bCSWStatus == CSWSTATUS_FUMEROLA) {
DPRINTF(UDMASS_BBB, (%s: Command Failed, res = %d\n,
Index: cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.42.2.29
diff -u -r1.42.2.29 scsi_da.c
--- cam/scsi/scsi_da.c 23 Nov 2002 23:21:42 - 1.42.2.29
+++ cam/scsi/scsi_da.c 19 Dec 2002 10:28:11 -
@@ -250,6 +250,14 @@
},
{
/*
+* Sony Key-Storage media fails in terrible ways without
+* both quirks.
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Sony, Storage Media, *},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
+ },
+ {
+ /*
* Sony DSC cameras (DSC-S30, DSC-S50, DSC-S70)
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, Sony, Sony DSC, *},
@@ -546,8 +554,10 @@
rcap = (struct scsi_read_capacity_data *)malloc(sizeof(*rcap),
M_TEMP,
- M_WAITOK);
-
+ M_WAITOK|M_ZERO);
+ scsi_ulto4b(313, (void *)rcap-length);
+ scsi_ulto4b(512, (void *)rcap-addr);
+
ccb = cam_periph_getccb(periph, /*priority*/1);
scsi_read_capacity(ccb-csio,
/*retries*/1,
@@ -1185,6 +1195,7 @@
softc-minimum_cmd_size = 10;
else
softc-minimum_cmd_size = 6;
+ printf(QUIRKS %04x MCS %d MATCH %p\n, softc-quirks,
+softc-minimum_cmd_size, match);
/*
* Block our timeout handler while we
@@ -1746,6 +1757,8 @@
dp = softc-params;
dp-secsize = scsi_4btoul(rdcap-length);
dp-sectors = scsi_4btoul(rdcap-addr) + 1;
+ printf(RDCAP SECSIZE %d\n, (int)dp-secsize);
+ printf(RDCAP SECTORS %d\n, (int)dp-sectors);
/*
* Have the controller provide us with a geometry
* for this disk. The only time the geometry
@@ -1765,6 +1778,7
VAX tinderbox failure
- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/dillon/tinderbox/vax/obj/local0/scratch/des/src/vax/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Dec 19 09:37:06 PST 2002 -- Kernel build for GENERIC completed on Thu Dec 19 10:28:44 PST 2002 -- Kernel build for LINT started on Thu Dec 19 10:28:44 PST 2002 -- === vesa Makefile, line 5401: warning: duplicate script for target geom_bsd.o ignored Makefile, line 5404: warning: duplicate script for target geom_mbr.o ignored /local0/scratch/dillon/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/dillon/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/dillon/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/dillon/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/dillon/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/dillon/src/sys/dev/ie/if_ie.c:778: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieget': /local0/scratch/dillon/src/sys/dev/ie/if_ie.c:1147: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/dev/ie/if_ie.c:1237: warning: passing arg 1 of `bcopy' discards qualifiers from pointer target type /local0/scratch/dillon/src/sys/dev/ie/if_ie.c:1237: warning: passing arg
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
This is a real mess but I finally got it to work. (Note
to John: both quirk entries are absolutely necessary,
everything stalls and dies without them).
Problem #1: RA_NO_CLEAR_UA quirk required in umass.c.
Problem #2: RA_NO_CLEAR_UA quirk code is broken,
causes CAM to think that the READ_CAPACITY
command succeed when it actually failed due
to the umass_cam_quirk_cb() function
changing the return status.
(Machine crashes on bogus capacity data,
junk that was sitting in the malloc'd
buffer which the machine thinks is real).
Problem #3: After fixing RA_NO_CLEAR_UA, CAM still
retries four times quickly and fails.
But at least it doesn't crash and burn.
This is odd... in this state /dev/da2
exists and if I run 'fdisk da2' it
does in fact work, as does dd'ing.
If I run 'fdisk da2' manually CAM
tries to do a READ CAPACITY and
gets a sense key indicating that the
media changed, and recovers from there,
except disklabel still doesn't work
(/dev only has da2, it doesn't have any
of the slice entries for some reason).
I tried bumping the number of CAM retries from 4
to 10. No joy.
I tried adding the NO_TEST_UNIT_READY quirk to
force UMASS to issue a start-unit command instead
of a test-unit-ready command.
That didn't work.
I tried adding a 0.3-second DELAY(30) between
retries.
Ahhh... THAT WORKED! The device takes over a
second before it TEST_UNIT_READY returns TRUE.
Ok, so here is the patch. I need help with two things.
First, are my RA_NO_CLEAR_UA bug fixes correct?
Second, does anyone have any ideas on how we can
make CAM/UMASS friendlier to devices which take
longer to get themselves going?Obviously
sticking a DELAY(30) in the middle of an
interrupt routine is not a good thing to do.
Is there any way to get CAM to poll the
device every once in a while to see if the
media is ready?
Note that 'camcontrol rescan correct_bus'
does not work. It does not cause cam to rescan
the USB device, it does not cause geom to pick
up on the fact that da2 is good. It doesn't seem
to do anything in fact :-(
-Matt
Index: sys/cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.118
diff -u -r1.118 scsi_da.c
--- sys/cam/scsi/scsi_da.c 18 Dec 2002 21:47:52 - 1.118
+++ sys/cam/scsi/scsi_da.c 19 Dec 2002 21:56:31 -
@@ -271,6 +271,16 @@
},
{
/*
+* Sony Key-Storage media fails in terrible ways without
+* both quirks. The auto 6-10 code doesn't do the job.
+* (note: The Sony diskkey is actually the MSYSTEMS
+* disk-on-key device).
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Sony, Storage Media, *},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
+ },
+ {
+ /*
* Sony DSC cameras (DSC-S30, DSC-S50, DSC-S70)
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, Sony, Sony DSC, *},
Index: sys/dev/usb/umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.67
diff -u -r1.67 umass.c
--- sys/dev/usb/umass.c 8 Nov 2002 07:57:42 - 1.67
+++ sys/dev/usb/umass.c 19 Dec 2002 23:05:13 -
@@ -345,6 +345,10 @@
UMASS_PROTO_SCSI | UMASS_PROTO_CBI,
NO_TEST_UNIT_READY | NO_START_STOP
},
+ { USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DISKONKEY, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ IGNORE_RESIDUE | NO_GETMAXLUN | RS_NO_CLEAR_UA
+ },
{ USB_VENDOR_OLYMPUS, USB_PRODUCT_OLYMPUS_C1, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
WRONG_CSWSIG
@@ -2606,7 +2610,7 @@
/* Getting sense data always succeeds (apart from wire
* failures).
*/
- if (sc-quirks RS_NO_CLEAR_UA
+ if ((sc-quirks RS_NO_CLEAR_UA)
csio-cdb_io.cdb_bytes[0] == INQUIRY
(csio-sense_data.flags SSD_KEY)
== SSD_KEY_UNIT_ATTENTION) {
@@ -2622,21 +2626,24 @@
* CCI)
*/
ccb-ccb_h.status = CAM_REQ_CMP;
- } else if ((sc-quirks RS_NO_CLEAR_UA) /* XXX */
+ } else if ((sc-quirks RS_NO_CLEAR_UA)
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
On Thu, 19 Dec 2002, Bernd Walter wrote: On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote: The panic described in 46176 has happened to me on -current. On -stable I have managed (very easily) to get the CAM layer vs UMASS layer into a confused state where the CAM layer thinks it is still attached but the UMASS layer thinks it has detached / cleaned everything out. In both cases it appears that memory is being freed by one side which is still being used by the other side but I haven't tracked down the exact cause. The umass driver uses a single sim for all umass devices. There are a lot of workarounds and bugs introduced because of this. Also there is a small static limit (IIRC 3) in the number of instances supported. [...] My intention is to rewrite the parts of umass to use multiple sims so LUNs and many instances actually work and hopefully a lot of other problems like this can be solved too. A SIM is meant to represent a single bus which multiple periphs can attach to. So on my laptop, which has multiple USB controllers, should call cam_sim_alloc() 3 times: uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 Right now though, cam_sim_alloc() is called once when the first umass device is detected and all devices are attached there. This is done so that the target id can be a primary key to lookup the softc (via devclass_get_softc). This is unnecessary since a pointer to the softc can be stashed in the sim_priv area and since umass_cam_action gets called with *sim, this is readily available. The static limit is 32 normally, 3 in the USB_DEBUG case. This is not a CAM limitation. If umass used CAM properly, LUNs would not be a problem. There are many ways USB interacts with CAM that are sub-optimal and sometimes incorrect. I haven't had time to immerse myself in USB-land and am pursuing updates to CAM to handle many different transport types instead of hacking what is there in current implementations of USB/1394/... (i.e. multiple duplicate cdb xlation routines) -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working).
On Thu, Dec 19, 2002 at 03:24:28PM -0800, Nate Lawson wrote: On Thu, 19 Dec 2002, Bernd Walter wrote: On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote: The panic described in 46176 has happened to me on -current. On -stable I have managed (very easily) to get the CAM layer vs UMASS layer into a confused state where the CAM layer thinks it is still attached but the UMASS layer thinks it has detached / cleaned everything out. In both cases it appears that memory is being freed by one side which is still being used by the other side but I haven't tracked down the exact cause. The umass driver uses a single sim for all umass devices. There are a lot of workarounds and bugs introduced because of this. Also there is a small static limit (IIRC 3) in the number of instances supported. [...] My intention is to rewrite the parts of umass to use multiple sims so LUNs and many instances actually work and hopefully a lot of other problems like this can be solved too. A SIM is meant to represent a single bus which multiple periphs can attach to. So on my laptop, which has multiple USB controllers, should call cam_sim_alloc() 3 times: No there is no direct relation to an usb bus and a sim. Each umass class device should have a sim on each own independend on which (usb)-bus it belongs. It is true that a SIM is meant to represent a bus, but the SCSI bus is with the umass entity. That is the same reason why two SCSI PCI cards have SIMs on each own even they could be on the same PCI bus. uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 Right now though, cam_sim_alloc() is called once when the first umass device is detected and all devices are attached there. This is done so that the target id can be a primary key to lookup the softc (via devclass_get_softc). This is unnecessary since a pointer to the softc can be stashed in the sim_priv area and since umass_cam_action gets called with *sim, this is readily available. Right. The static limit is 32 normally, 3 in the USB_DEBUG case. This is not a CAM limitation. If umass used CAM properly, LUNs would not be a problem. And what if I want to connect 40 umass devices - possibly on the same usb bus? No it is not a CAM problem - it's a problem on the cam interface implementation in the umass driver. LUNs on umass currently don't work. E.g. there are many workarounds to handle disconection of devices. If you attach an USB device you effectively add new ID to a simulated bus and then we trigger cam to rescan the whole virtual bus. The same happens when a device gets disconnected. A special handling has to be done for the last device, because without it the virtual bus is removed and can't be rescanned. It would be much easier to just connect and disconnect a bus on each own for each umass device - even if a umass device can only have a single ID. That LUNs don't work has something to do that the code is stuffed with special handling for case introduced because of the single sim handling - in fact CAM knows the correct number of available LUNs and scans for all of them but the umass driver failed to handle them correctly. It has become difficult to maintain without good reasons. Well - it's possible to add another hack to get LUNs working, but I prefer a new basic design. I believe the cause for this design is that the cam interfacing was taken from the vpo driver which itself was designed for a single ZIP drive. There are many ways USB interacts with CAM that are sub-optimal and sometimes incorrect. I haven't had time to immerse myself in USB-land and am pursuing updates to CAM to handle many different transport types instead of hacking what is there in current implementations of USB/1394/... (i.e. multiple duplicate cdb xlation routines) Exactly that's what SIMs should do - abstract the transport layer. And the transport layer for umass is SCSI/BBB and others. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On Thu, 19 Dec 2002, Matthew Dillon wrote:
Yes, this is a USB DiskKey - UMASS storage, SCSI over bulk only device.
I've done some further testing on both -current and -stable. I cannot
get the device to work unless I have the quirk entry in scsi_da.c.
-Current has a quirk table for umass.c and already has a flag which
disables the residue test. The patch for current thus does not require
#if 0'ing out that code, only a quirk entry. Since I don't need any
hacks beyond what is there already I am going to commit the two quirk
entries for -current now.
Please respect the maintainer of da(4). There's info about quirk
documentation at:
http://www.root.org/~nate/freebsd/quirks.html
I still have a broken finger and a job so slow responses do not mean I am
ignoring you.
However, I am still unable to get the device to work properly in
-Current. This is what happens (see below).
test2 kernel: umass0: Sony USB Storage Media, rev 1.10/2.00, addr 2
test2 kernel: umass0: Get Max Lun not supported (IOERROR)
test2 kernel: da2 at umass-sim0 bus 0 target 0 lun 0
test2 kernel: da2: Sony Storage Media 2.51 Removable Direct Access SCSI-0 device
test2 kernel: da2: 1.000MB/s transfers
test2 kernel: da2: Attempt to query device size failed: UNIT ATTENTION, Medium not
present
Bus scan is probably happening before the device is fully powered up.
One problem I noticed was that umass_cam_rescan() doesn't fill out the ccb
properly, leaving timeout as 0 for instance. This probably won't hurt but
I'm not sure. Another bug available from cursory overview is:
if (csio-ccb_h.flags CAM_CDB_POINTER) {
cmd = (unsigned char *) csio-cdb_io.cdb_ptr;
} else {
cmd = (unsigned char *) csio-cdb_io.cdb_bytes;
}
The is extraneous. Not sure why this doesn't bomb horribly later.
test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error
test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition
test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0
test2 kernel: (da2:umass-sim0:0:0:0): Medium not present
test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data)
CAM retries the CCB as requested by scsi_da.c in daopen().
test2 kernel: Opened disk da2 - 6
But then I get this:
test2 kernel: (da2:umass-sim0:0:0:0): Not ready to ready change, medium may have
changed
test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data)
(no retry occurs)
And if I tell cam to rescan a different Lun it works:
Because the device has had time to power up.
I am not sure what is going on but I think in -current CAM is
exhausting its retries too quickly (the messages are instantanious)
and not giving the device enough time to boot up. This is because,
I believe, the usb controller is now a kerneland thread instead of
a userland usbd and is responding instantly to the device presence.
No, umass is attaching before the device is ready. Note the difference in
delay between camcontrol rescan on a SPI bus vs. USB. The SPI controller
is taking the appropriate time per device for it to respond to select.
umass_cam_attach attempts to delay the bus scan to have the same effect
but may not be working properly here. I have no idea what the USB spec
says here.
I would have expected 'camcontrol rescan 2:0:0' but it doesn't.
It just says:
# camcontrol rescan 2:0:0
Re-scan of 2:0:0 was successful
But then doesn't do anything.
umass is not calling the attach code again for some reason.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
if_dc: ethernet address now reported as 00:00:00:00:00:00
I have been recently experimenting with FreeBSD-current and have noticed a bug in dc network driver that it doesn't set the ethernet address correctly (I have seen this problem reported before on current, but I was hoping it could be fixed before 5.0-release). I am trying to find a fix myself but I am still getting comfortable with sources. Here is my dmesg output. dc0: Macronix 98715AEC-C 10/100BaseTX port 0xe000-0xe0ff mem 0xef005000-0xef0050ff irq 10 at device 9.0 on pci0 dc0: Ethernet address: 00:00:00:00:00:00 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On Thu, Dec 19, 2002 at 04:25:40PM -0800, Nate Lawson wrote:
if (csio-ccb_h.flags CAM_CDB_POINTER) {
cmd = (unsigned char *) csio-cdb_io.cdb_ptr;
} else {
cmd = (unsigned char *) csio-cdb_io.cdb_bytes;
}
The is extraneous. Not sure why this doesn't bomb horribly later.
Because cdb_bytes is an array not a pointer. The expression
csio-cdb_io.cdb_bytes points to the whole array and has the type
u_int8_t (*)[IOCDBLEN], when cast to unsigned char *, the value will be
the same as just csio-cdb_io.cdb_bytes.
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
: : -Current has a quirk table for umass.c and already has a flag which : disables the residue test. The patch for current thus does not require : #if 0'ing out that code, only a quirk entry. Since I don't need any : hacks beyond what is there already I am going to commit the two quirk : entries for -current now. : :Please respect the maintainer of da(4). There's info about quirk :documentation at: : http://www.root.org/~nate/freebsd/quirks.html : :I still have a broken finger and a job so slow responses do not mean I am :ignoring you. Well, what do you think about the Quirk entry? I tested both stable and current with and without the quirk entry, and with various combinations of options. It doesn't work without thet quirk entry. : test2 kernel: umass0: Sony USB Storage Media, rev 1.10/2.00, addr 2 : test2 kernel: umass0: Get Max Lun not supported (IOERROR) : test2 kernel: da2 at umass-sim0 bus 0 target 0 lun 0 : test2 kernel: da2: Sony Storage Media 2.51 Removable Direct Access SCSI-0 device : test2 kernel: da2: 1.000MB/s transfers : test2 kernel: da2: Attempt to query device size failed: UNIT ATTENTION, Medium not :present : :Bus scan is probably happening before the device is fully powered up. :One problem I noticed was that umass_cam_rescan() doesn't fill out the ccb :properly, leaving timeout as 0 for instance. This probably won't hurt but :I'm not sure. Another bug available from cursory overview is: I'll take a look at the attach code. It would be cool if there were something easy we could do there, but I am not optimistic considering the fact that the device responds to the control channel queries just fine long, long before it tells us that the media is ready. : test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 : test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error : test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition : test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 : test2 kernel: (da2:umass-sim0:0:0:0): Medium not present : test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) : :CAM retries the CCB as requested by scsi_da.c in daopen(). Yes, I know. That wasn't really my question. This is USB we are talking about here after all. : test2 kernel: (da2:umass-sim0:0:0:0): Not ready to ready change, medium may have :changed : test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) : (no retry occurs) : :And if I tell cam to rescan a different Lun it works: : :Because the device has had time to power up. That is my assumption too, but then again the device responds just fine to the control channel commands (getting the device name and all of that rot). I'm hoping it is as simple as a timeout parameter somewhere but where to look... : I am not sure what is going on but I think in -current CAM is : exhausting its retries too quickly (the messages are instantanious) : and not giving the device enough time to boot up. This is because, : I believe, the usb controller is now a kerneland thread instead of : a userland usbd and is responding instantly to the device presence. : :No, umass is attaching before the device is ready. Note the difference in :delay between camcontrol rescan on a SPI bus vs. USB. The SPI controller :is taking the appropriate time per device for it to respond to select. :umass_cam_attach attempts to delay the bus scan to have the same effect :but may not be working properly here. I have no idea what the USB spec :says here. Hmm. Any idea where I should look? : I would have expected 'camcontrol rescan 2:0:0' but it doesn't. : It just says: : : # camcontrol rescan 2:0:0 : Re-scan of 2:0:0 was successful : : But then doesn't do anything. : :umass is not calling the attach code again for some reason. : :-Nate Is it supposed to? I'm looking for guidance. -- I found another couple of bugs, this time in OHCI's DMA buffer chaining code. A patch for this with additional debugging code is included below (for current). There are two bugs. I do not know if -stable is effected. First, the calculation of dataphysend is totally bogus. You can just take the physical address and add (len - 1) to it. You have to take the virtual address, add len - 1 to it, and convert it to a physical address. I can crash my machine simply by doing a 'newfs -f 1024 -b 8192 /dev/da2s1a' On the disk-on-key USB device. Second, I believe the OpenBSD and NetBSD code is broken. The range can be one or two pages, but the remaining bytes may be less then one page and this has to be taken into account. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: Panic: memory modified after free
On Thu, 19 Dec 2002, Gavin Atkinson wrote: Running 5.0-RC as of yesterday on i386. background fsck was in progress, but other than that system was idle. Logged in as root on the console, had cd'd to a ports directory. (note that it panics almost instantly when using the console, but lasts upto 10 minutes when in use over ssh) Running make deinstall triggered this panic: Memory modified after free 0xc1891c00(1020) panic: Most recently used by none [snip backtrace] The machine seems perfectly stable in single user mode. It also seems pretty stable at the moment with linux emulation, usbd, sendmail, ipv6, nfs server and moused enables commented out of rc.conf. I will try to add one at a time tonight to determine which is at fault. Update: I re-cvsupped (to 19 Dec 14:00 GMT) , and recompiled world and kernel. I can no longer cause the panic. I then (out of interest) dropped back to the old kernel that was panicing (18 Dec 12:00 GMT), but run with the new world, and could not recreate the panic. I therefore believe that one of the userland binaries that I replaced was tickling the bug, and now I have replaced that binary, the problem no longer occurs. So, unless anyone can think of a better reason for this, I suspect there is a kernel use-after-free bug laying dormant. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic: memory modified after free
On Fri, 20 Dec 2002, Gavin Atkinson wrote: Running 5.0-RC as of yesterday on i386. background fsck was in progress, but other than that system was idle. Logged in as root on the console, had cd'd to a ports directory. (note that it panics almost instantly when using the console, but lasts upto 10 minutes when in use over ssh) Running make deinstall triggered this panic: Memory modified after free 0xc1891c00(1020) panic: Most recently used by none Update: I re-cvsupped (to 19 Dec 14:00 GMT) , and recompiled world and kernel. I can no longer cause the panic. I then (out of interest) dropped back to the old kernel that was panicing (18 Dec 12:00 GMT), but run with the new world, and could not recreate the panic. I therefore believe that one of the userland binaries that I replaced was tickling the bug, and now I have replaced that binary, the problem no longer occurs. There were several bugs fixed between those dates, most importantly this one. It is unlikely the userland changes that day could mask a bug like that. mckusick2002/12/18 11:50:28 PST Modified files: sys/ufs/ffs ffs_snapshot.c Log: Fix corruption introduced in previous delta. Reported by:Aurelien Nephtali [EMAIL PROTECTED] Sponsored by: DARPA NAI Labs. Revision ChangesPath 1.57 +12 -4 src/sys/ufs/ffs/ffs_snapshot.c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
:First, the calculation of dataphysend is totally bogus. :You can just take the physical address and add (len - 1) :to it. You have to take the virtual address, add len - 1 :to it, and convert it to a physical address. I can :crash my machine simply by doing a God, my grammer is getting really bad. I meant, You can't just take the physical address and add (len - 1) to it, not that you can :-) Then the sentence makes sense. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Patch to sys/i386/isa/vesa.c (Need check before submit pls)
This is the first patch I've ever submitted.
In fact, I can't even take credit for it - some body submitted it to a
newsgroup last year. But I think it should be integrated into the vesa.c
code.
If anyone has time to read over it, I'd appreciate any suggestions, an
help with the one question below.
Tested on FreeBSD 4.7-STABLE (as of a week or so ago). I would have used a
-CURRENT box but I don't have one any more :-/ Sorry if this causes
problems.
The code is designed to set the default refresh rate for the console to
100Hz, when you set the resolution with vidcontrol to VESA_800x600.
It first flips to 1024x768, and saves some registers, then flips back to
800x600 and applies those to get the 100Hz.
I'm wanting to request this patch be included into FreeBSD, because I've
started using FreeBSD on a daily basis in console-only mode, and at
resolutions about the default 600x400 that is run a 70Hz, the refresh rate
drops to 60Hz which hurts the eyes for a while.
As you have to compile SC_PIXEL_MODE into the kernel, and do 'vidcontrol
VESA_800x600' for this to work, we're not changing any defaults that will
effect everyone.
I would really have loved it if the default driver or vidcontrol could let
you set whatever refresh rate you want, but I have no idea why they do
not. to me it seems like an obvious extension of what is present.
The question is: Does anyone know how this code can be changed to set the
refresh rate to something a little saner like 85Hz, which is a good
standard that most recent made in the last 5 years can support?
Finally, the code diff:
--- src,orig/sys/i386/isa/vesa.cSat Jan 29 18:08:40 2000
+++ src/sys/i386/isa/vesa.c Thu Mar 16 11:44:31 2000
@@ -1019,7 +1016,25 @@
if (!(info.vi_flags V_INFO_GRAPHICS))
info.vi_flags = ~V_INFO_LINEAR;
- if (vesa_bios_set_mode(mode | ((info.vi_flags V_INFO_LINEAR) ? 0x4000 : 0)))
+ if (mode == M_VESA_800x600) { /* XXX ignores V_INFO_LINEAR */
+ unsigned char crtc[0x19];
+ unsigned char reg;
+ if (vesa_bios_set_mode(mode))
+ return 1;
+ for (reg=0;reg0x19;++reg) {
+ outb(0x3d4,reg);
+ crtc[reg]=inb(0x3d5);
+ }
+ if (!vesa_bios_set_mode(M_VESA_1024x768)) {
+ outb(0x3d4,0x11);
+ outb(0x3d5,crtc[0x11]0x7f);
+ for (reg=0;reg0x19;++reg) {
+ outb(0x3d4,reg);
+ outb(0x3d5,crtc[reg]);
+ }
+ }
+ } else
+ if (vesa_bios_set_mode(mode | ((info.vi_flags V_INFO_LINEAR) ? 0x4000 :
+0)))
return 1;
if (adp-va_info.vi_flags V_INFO_LINEAR)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sys/boot/sparc64/loader In file included from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: machine/asm.h:105:1: warning: __FBSDID redefined In file included from machine/asm.h:46, from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: /tinderbox/sparc64/src/sys/sys/cdefs.h:239:1: warning: this is the location of the previous definition /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: `zipfs_fsops' undeclared here (not in a function) /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: initializer element is not constant /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: (near initialization for `file_system[2]') *** Error code 1 Stop in /tinderbox/sparc64/src/sys/boot/sparc64/loader. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/boot/sparc64. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/boot. *** Error code 1 Stop in /tinderbox/sparc64/src/sys. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
On Fri, Dec 20, 2002 at 12:27:59PM +1100, Darren Reed wrote the words in effect of:
Well someone has blown my cover from developers and has asked here
what I was trying to be more surrepticious about!
In some email I received from Sam Leffler, sie wrote:
A teeny-weeny issue I would like to discuss, is that we make the pfil(9)
hooks code default in 5.0, and remove the kernel option; this is because
it creates problems when PFIL_HOOKS is not in the (e.g. GENERIC) kernel,
and someone tries to load the ipfilter kernel module (ipl.ko). [1]
I have discussed this with Darren, but would just like to make it
public, so it can be discussed by the release engineers etc. I
apologize but I do not have patches for this.
Enabling PFIL_HOOKS changes various code paths. Doing this so late in the
release cycle is a bad idea. I also recall that there is a performance
penalty (at least in the bridge code) for having this enabled.
There are callouts in both the IPv{4,6} paths for input and output with
PFIL_HOOKS and also bridging.
PFIL_HOOKS is 1 .c file and 1 .h file and a very small amount of code.
Also, given its generic nature, I'd hope that ipfw* could eventually
move to use it for intercepting packets along the above code paths.
The bloat factor from including it in the base kernel should be very
small and perhaps the impact of the code being active in those packet
paths close to immeasurable (I hope.)
Both issues make it seem like it should stay an option for 5.0.
I agree with this.
Maybe we should put in the release notes, that:
PFIL_HOOKS is required for IPFILTER
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Apparently, On Fri, Dec 20, 2002 at 03:26:36AM +, Mike Barcroft said words to the effect of; -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sys/boot/sparc64/loader In file included from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: machine/asm.h:105:1: warning: __FBSDID redefined In file included from machine/asm.h:46, from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15: /tinderbox/sparc64/src/sys/sys/cdefs.h:239:1: warning: this is the location of the previous definition /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: `zipfs_fsops' undeclared here (not in a function) /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: initializer element is not constant /tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: (near initialization for `file_system[2]') *** Error code 1 Fixed, my apologies. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Maybe we should put in the release notes, that: PFIL_HOOKS is required for IPFILTER The right thing is to force the dependency in the code (I don't think there's a way to express it to config). The ipfilter code should probably have something like #ifndef PFIL_HOOKS #error You must specify PFIL_HOOKS when using ipfilter #endif Unfortunately there's no way that I know to express this if ipfilter is loaded as a module. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
I fixed a serious DMA physical address translation bug in OHCI today.
Look on the lists today for this message. Message and patch enclosed.
Note that this fixes one bug in FreeBSD's implementation and a second
bug that is NetBSD/OpenBSD specific. I would appreciate it if someone
would forward this information to the NetBSD/OpenBSD folks.
These were very serious bugs.
-Matt
:Date: Thu, 19 Dec 2002 17:11:32 -0800 (PST)
:From: Matthew Dillon [EMAIL PROTECTED]
:Message-Id: [EMAIL PROTECTED]
:To: Nate Lawson [EMAIL PROTECTED]
:Cc: [EMAIL PROTECTED]
:Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working)
:References: [EMAIL PROTECTED]
:Sender: [EMAIL PROTECTED]
:List-ID: freebsd-current.FreeBSD.ORG
:List-Archive: http://docs.freebsd.org/mail/ (Web Archive)
:List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions)
:List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-current
:List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-current
:X-Loop: FreeBSD.ORG
:Precedence: bulk
:...
:
Index: ohci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.116
diff -u -r1.116 ohci.c
--- ohci.c 9 Dec 2002 01:41:24 - 1.116
+++ ohci.c 20 Dec 2002 01:02:11 -
@@ -493,17 +493,17 @@
u_int32_t intr, tdflags;
int offset = 0;
int len, curlen;
+ int orig_len;
usb_dma_t *dma = xfer-dmabuf;
u_int16_t flags = xfer-flags;
DPRINTFN(alen 4096,(ohci_alloc_std_chain: start len=%d\n, alen));
- len = alen;
+ orig_len = len = alen;
cur = sp;
-
dataphys = DMAADDR(dma, 0);
- dataphysend = OHCI_PAGE(dataphys + len - 1);
+ dataphysend = OHCI_PAGE(DMAADDR(dma, len - 1));
tdflags = htole32(
(rd ? OHCI_TD_IN : OHCI_TD_OUT) |
(flags USBD_SHORT_XFER_OK ? OHCI_TD_R : 0) |
@@ -518,8 +518,8 @@
/* The OHCI hardware can handle at most one page crossing. */
#if defined(__NetBSD__) || defined(__OpenBSD__)
- if (OHCI_PAGE(dataphys) == OHCI_PAGE(dataphysend) ||
- OHCI_PAGE(dataphys) + OHCI_PAGE_SIZE == OHCI_PAGE(dataphysend))
+ if (OHCI_PAGE(dataphys) == dataphysend ||
+ OHCI_PAGE(dataphys) + OHCI_PAGE_SIZE == dataphysend)
#elif defined(__FreeBSD__)
/* XXX This is pretty broken: Because we do not allocate
* a contiguous buffer (contiguous in physical pages) we
@@ -527,7 +527,7 @@
* So check whether the start and end of the buffer are on
* the same page.
*/
- if (OHCI_PAGE(dataphys) == OHCI_PAGE(dataphysend))
+ if (OHCI_PAGE(dataphys) == dataphysend)
#endif
{
/* we can handle it in this TD */
@@ -544,6 +544,8 @@
/* must use multiple TDs, fill as much as possible. */
curlen = 2 * OHCI_PAGE_SIZE -
OHCI_PAGE_MASK(dataphys);
+ if (curlen len) /* may have fit in one page */
+ curlen = len;
#elif defined(__FreeBSD__)
/* See comment above (XXX) */
curlen = OHCI_PAGE_SIZE -
@@ -568,6 +570,9 @@
dataphys, dataphys + curlen - 1));
if (len == 0)
break;
+ if (len 0)
+ panic(Length went negative: %d curlen %d (dma %p offset %08x
+dataphysend %p currentdataphysend %p, len, curlen, *dma, (int)offset, (void
+*)dataphysend, (void *)OHCI_PAGE(DMAADDR(dma,0) + orig_len - 1));
+
DPRINTFN(10,(ohci_alloc_std_chain: extend chain\n));
offset += curlen;
cur = next;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Maybe we should put in the release notes, that: PFIL_HOOKS is required for IPFILTER The right thing is to force the dependency in the code (I don't think there's a way to express it to config). The ipfilter code should probably have something like #ifndef PFIL_HOOKS #error You must specify PFIL_HOOKS when using ipfilter #endif Unfortunately there's no way that I know to express this if ipfilter is loaded as a module. Duh, there'll probably be unresolved symbols if you try to load ipl.ko w/o PFIL_HOOKS defined in the kernel. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
In message: [EMAIL PROTECTED] Dan Nelson [EMAIL PROTECTED] writes: : Ooh. you get an all-zero address. Mine comes up with I have this problem on a card. That's good since I introduced it into the kernel :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ntp problems on sparc
Has anyone else run into the following when trying to run ntpd on sparc? Dec 20 05:51:37 panther2 ntpd[416]: bind() fd 5, family 2, port 123, addr 216.136.204.96, in_classd=0 flags=1 fails: Can't assign requested address Dec 20 05:51:41 panther2 ntpd[416]: sendto(216.136.204.18): Bad file descriptor Dec 20 05:51:42 panther2 ntpd[416]: sendto(216.136.204.118): Bad file descriptor Dec 20 05:51:44 panther2 ntpd[416]: sendto(216.136.204.21): Bad file descriptor Dec 20 05:51:53 panther2 ntpd[416]: sendto(216.136.204.27): Bad file descriptor Kris msg49097/pgp0.pgp Description: PGP signature
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
In the last episode (Dec 19), User Phrackbox said: I have been recently experimenting with FreeBSD-current and have noticed a bug in dc network driver that it doesn't set the ethernet address correctly (I have seen this problem reported before on current, but I was hoping it could be fixed before 5.0-release). I am trying to find a fix myself but I am still getting comfortable with sources. Here is my dmesg output. dc0: Macronix 98715AEC-C 10/100BaseTX port 0xe000-0xe0ff mem 0xef005000-0xef0050ff irq 10 at device 9.0 on pci0 dc0: Ethernet address: 00:00:00:00:00:00 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Ooh. you get an all-zero address. Mine comes up with dc0: Davicom DM9102A 10/100BaseTX port 0xa800-0xa8ff mem 0xf300-0xf3ff irq 11 at device 12.0 on pci0 dc0: Ethernet address: c0:00:c0:00:c0:00 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I actually like mine; it makes it easy to spot my packets on tcpdumps :) It looks like the MAC address is stored in a different place on each brand of card, so it's not surprising that the driver gets it wrong sometimes. Take a look at if_dc.c:2131-2172 to see what I mean. Try using dc_read_eeprom in a loop to print the first 512 or bytes, then determine the true offset by searching for your MAC address in there (it's usually stamped or printed on the card somewhere). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
`cat /dev/io` leads to system lockup.
On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its knees by doing # cat /dev/io While I understand that this isn't exactly something one would normally be doing, is it really something that should bring the system down? -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg49099/pgp0.pgp Description: PGP signature
5.0 RC1 install fails with message Loading module if_awi.ko failed
I have been running 5.0 for a while and decided to install 5.0-RC1 on a Pentium 100 with 2GB HDD and 16MB ram that was lying around. I am seeing this weird situation where: - installation aborts with the message Loading Module if_awi.ko Failed BayStack 660 and Others and hangs up after the message /stand/sysinstall running on ... - i have tried different snapshots ( including 20001220 ) and used both floppy and CDROM drive to bootup. DP2 install stops few steps before the RC1. - Then, decided to try 4.7 and it installed without a hitch. Any idea? Google search or mailing list search did not produce any results. Thanks. ...Camilla... __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Thoughts about ports freeze
On Fri, 20 Dec 2002 07:51:48 +0100, [EMAIL PROTECTED] (Dirk Meyer) said: Dirk Maxim Sobolev wrote, Perhaps we could just branch out current state of the tree and unlock it for normal use, while allow to commit onto the RE branch only after Dirk Moving the tags can give us fine control withouth having to branch or freeze. Dirk I have 29 updates/committs in the queue, waiting for the freeze is over. Dirk No offense, I know the problems, but I think the freeze is way to long. Hi, While we are on this topic, what happens after 5.0-CURRENT ? I understand 5.0-RELEASE, but on the -CURRENT front ? Will we have to wait till the release for the unfreeze to happen. Cause, the way it is going, it seems as tho' the freeze is gonna stay till the 2nd quarter of 2003 or something. Just my thougts, no offense meant :) Regards Sid -- Where there's a will, there's an Inheritance Tax. Sid Carter - http://khader.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntp problems on sparc
On Thu, 19 Dec 2002 21:59:54 -0800, Kris Kennaway wrote: Has anyone else run into the following when trying to run ntpd on sparc? Dec 20 05:51:37 panther2 ntpd[416]: bind() fd 5, family 2, port 123, addr 216.136.204.96, in_classd=0 flags=1 fails: Can't assign requested address The port (123) is probably in use or the IP it's trying to bind to isn't assigned to this machine. Dec 20 05:51:41 panther2 ntpd[416]: sendto(216.136.204.18): Bad file descriptor Dec 20 05:51:42 panther2 ntpd[416]: sendto(216.136.204.118): Bad file descriptor Dec 20 05:51:44 panther2 ntpd[416]: sendto(216.136.204.21): Bad file descriptor Dec 20 05:51:53 panther2 ntpd[416]: sendto(216.136.204.27): Bad file descriptor DS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ssh authentification broken, only public keys work
Hi all, Since yesterday I cannot login to my CURRENT machine anymore after a world and reboot ... I really hope this doesn't got MFC'd to RELENG_5_0 ... debug1: rcvd SSH_CMSG_AUTH_TIS debug3: mm_pam_init_ctx debug3: mm_request_send entering: type 42 debug3: monitor_read: checking request 42 debug3: mm_answer_pam_init_ctx debug3: mm_request_send entering: type 43 debug3: mm_request_receive entering debug3: mm_pam_init_ctx: waiting for MONITOR_ANS_PAM_INIT_CTX debug3: mm_request_receive_expect entering: type 43 debug3: mm_request_receive entering debug3: mm_pam_query debug3: mm_request_send entering: type 44 debug3: monitor_read: checking request 44 debug3: mm_answer_pam_query debug3: ssh_msg_recv entering debug3: ssh_msg_send: type 1 ssh_msg_send: write debug1: Calling cleanup 0x8061180(0x0) debug1: PAM: cleanup debug3: mm_pam_query: waiting for MONITOR_ANS_PAM_QUERY debug3: mm_request_receive_expect entering: type 45 debug3: mm_request_receive entering Then the connection times just out. The ssh_msg_send: write message appears without debug mode. Note that I did run mergemaster ... pam files are all on their place. Somthing is completly screwed up. There are a few posts in google indicating that other have this problem too. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `cat /dev/io` leads to system lockup.
On Fri, 20 Dec 2002, Sean Kelly wrote: On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its knees by doing # cat /dev/io While I understand that this isn't exactly something one would normally be doing, is it really something that should bring the system down? You're running as root. So does yes /dev/da0 and cat /dev/urandom /dev/mem and ... (infinity) -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ssh authentification broken, only public keys work
On 20 Dec, Martin Blapp wrote: Hi all, Since yesterday I cannot login to my CURRENT machine anymore after a world and reboot ... I really hope this doesn't got MFC'd to RELENG_5_0 ... snip debug I got this tonight on my ultra. I thought it was sparc64 specific, glad I saw your post. I cvsup'd 2 days ago. Im going to build OpenSSH from ports and see if it has the same error. -M To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Thoughts about ports freeze
in message [EMAIL PROTECTED], wrote Sid Carter thusly... On Fri, 20 Dec 2002 07:51:48 +0100, [EMAIL PROTECTED] (Dirk Meyer) said: Dirk I have 29 updates/committs in the queue, waiting for the freeze is over. Dirk No offense, I know the problems, but I think the freeze is way to long. the way it is going, it seems as tho' the freeze is gonna stay till the 2nd quarter of 2003 or something. Just my thougts, no offense meant :) ice age cometh. get thine blankie und hoard the nuts. :-] - parv -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
